Guide Measure PHP OPcache Performance in aaPanel

Guide Measure PHP OPcache Performance in aaPanel - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: aaPanel (https://adminsforum.com/Forum-aapanel)
+---- Forum: aaPanel Guides & Tutorials (https://adminsforum.com/Forum-aapanel-guides-tutorials)
+----- Forum: aaPanel PHP & Extensions Guides (https://adminsforum.com/Forum-aapanel-php-extensions-guides)
+----- Thread: Guide Measure PHP OPcache Performance in aaPanel (/Thread-guide-measure-php-opcache-performance-in-aapanel)

Measure PHP OPcache Performance in aaPanel - DEV - 10-14-2026

OPcache stores compiled PHP bytecode so PHP-FPM can reuse it instead of compiling the same scripts for every request. This guide measures that effect on a small WordPress lab and explains how to verify the serving runtime.

Test environment
aaPanel Free 8.0.7, Ubuntu 22.04.5, PHP 8.5.11, Nginx and WordPress. OPcache was already enabled before the experiment. We temporarily disabled it for the comparison and left it enabled afterwards. No production website was used.

1. Confirm the PHP version serving the website
Open Website → your site and inspect its PHP version. Our site used PHP 8.5 through /tmp/php-cgi-85.sock. A command-line PHP result alone cannot prove what PHP-FPM is doing: CLI and FPM may load different configuration files.
Read Check PHP OPcache: CLI vs PHP-FPM first if those results disagree.

2. Back up the active configuration
In App Store → Installed → PHP-8.5 → Setting, inspect the configuration and available extensions. Interface labels depend on the panel release. Confirm the active FPM php.ini before editing; our FPM runtime loaded /www/server/php/85/etc/php.ini, while CLI loaded php-cli.ini.
Keep a backup and working SSH access. A setting change affects the websites sharing that PHP version. Schedule a suitable maintenance window for a busy server.

3. Use a measured starting configuration
Our retained lab settings were:

Code:

[opcache]
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

The memory value is MiB. The file setting controls the script-cache table size; the actual key capacity may differ from the number configured. Check the runtime rather than assuming they are identical.
Timestamp validation allows changed files to be detected; the revalidation interval controls how frequently checks occur. Disabling validation requires a reliable deployment invalidation process. We kept it enabled and did not change JIT settings.
Do not increase these values merely because traffic increased. Look for cache exhaustion, restarts and the application’s script count, while reserving RAM for other services.

4. Validate and reload the correct pool
Our SSH checks were:

Code:

/www/server/php/85/sbin/php-fpm -t
/etc/init.d/php-fpm-85 reload

Validation passed before each reload. Syntax success does not prove the application works: check important pages and error logs afterwards. Restore the backup and reload if the change causes failures.

5. Verify OPcache through PHP-FPM privately
Our diagnostic script used opcache_get_status(false) and php_ini_loaded_file() through the private Unix socket. It was outside the website root. Passing false excludes the detailed cached-script path listing.
The enabled phase reported FPM SAPI fpm-fcgi, PHP 8.5.11, 532 cached scripts, about 29MiB used and 99MiB free, with zero out-of-memory and hash restarts at that observation. These values describe this small workload, not the needs of every WordPress installation.
Do not publish phpinfo or cache status on an unprotected URL: configuration and paths can disclose server details. Remove temporary diagnostics when finished.

6. Separate page caching from bytecode caching
A full-page cache HIT may avoid PHP entirely. We used unique query strings and verified Nginx-Cache: BYPASS under our existing rules. Query strings do not universally bypass caches; check your own configuration and response headers.
Each phase used 20 warmup requests followed by 20 measured requests at concurrency 2. Requests used loopback HTTPS with normal certificate validation. This isolates much of the network variation but does not represent a remote visitor’s full browser experience.

Filename: opcache-comparison-20261014.jpg Size: 117.41 KB Yesterday, 12:13 PM

AdminsForum formatted transcript of the original experiment, not a terminal screenshot.

7. Interpret the results

OPcache off: 20/20 HTTP 200; median time to first byte 490ms; small-sample p95 555ms.
OPcache on: 20/20 HTTP 200; median time to first byte 168ms; small-sample p95 190ms.

This workload was faster with OPcache enabled. Twenty requests give limited tail-latency evidence and do not establish maximum visitor capacity. Repeat tests on expensive pages and representative workloads before making production promises.
Runtime hit/miss counters can include warmup and other requests since the cache started; do not treat a cumulative hit ratio as the measured phase alone.

8. Monitor and revisit sizing
Inspect memory used/free/wasted, cached-script count, misses and restart counters over a representative period. An exhausted cache may need additional memory or key capacity; frequent deployments and invalidation also affect results. Check PHP errors and memory pressure alongside cache statistics.
OPcache does not replace SQL indexes, object caching or page caching. Use measured PHP-FPM worker limits to control concurrent process memory separately.

Reference: Official PHP OPcache configuration documentation.