PHP 8, OPcache, and FPM Tuning for Magento

PHP tuning is where a lot of Magento speed hides

Magento runs on PHP, and how PHP is configured has a large effect on performance that has nothing to do with Magento's own code. A store on a supported PHP version can still be slow because PHP, OPcache, and PHP-FPM are left near defaults.

The defaults are sized for small applications, and Magento is not small. Tuning PHP for the codebase and the traffic is one of the higher-impact changes available to a store, and it lives entirely in the server configuration rather than in the application.

This article covers OPcache sizing, the realpath cache, PHP-FPM process management, memory and timeouts, and where JIT does and does not help on Magento 2.4.x with PHP 8.3 and 8.4.

Confirm the PHP version first

Tuning starts with running a supported version. Magento 2.4.x pins specific PHP versions, and recent releases support PHP 8.3 and 8.4.

Confirm the version with php -v on both the command line and the web SAPI, since they can differ. Tuning an unsupported or mismatched version is wasted effort, because the store should be on a supported one before anything else.

With the version confirmed, the tuning below applies to how that PHP runs Magento. The single biggest lever is OPcache.

OPcache: size it for Magento

OPcache stores compiled PHP bytecode so files are not recompiled on every request. Magento has a very large number of files, and a default OPcache cannot hold them all.

Two settings matter most: opcache.memory_consumption, which needs to be generous for Magento, and opcache.max_accelerated_files, which must be high enough to cover the tens of thousands of files Magento loads. Too low, and OPcache evicts and recompiles constantly.

Turn off timestamp validation in production

By default OPcache checks whether each file changed on disk, on a schedule, so it can recompile updated files. In production this check is wasted work, because code only changes on deploy.

Setting opcache.validate_timestamps to off removes that filesystem check from every request. It is safe in production because the deploy process clears OPcache when code changes, so there is nothing to detect between deploys.

This is one of the cleanest production wins. It costs nothing and removes a per-request filesystem check across a codebase with thousands of files.

The realpath cache

PHP resolves file paths through the realpath cache, and Magento's deep directory structure exercises it heavily. A realpath cache that is too small forces PHP to resolve paths repeatedly.

Raising realpath_cache_size and realpath_cache_ttl lets PHP remember more resolved paths for longer. On Magento, with its many nested files, this is a small change with a measurable effect.

It is easy to overlook because it is not Magento-specific, but Magento's file layout is exactly the kind that benefits from it. Tuning it alongside OPcache addresses the two file-related costs together.

PHP-FPM process management

PHP-FPM runs the pool of worker processes that handle requests, and how that pool is managed decides concurrency. The process manager mode can be static, dynamic, or on demand.

Static keeps a fixed number of workers always ready, dynamic scales between a minimum and maximum, and on demand starts workers only when needed. For a busy store, static or a well-configured dynamic pool usually serves best, because starting workers on demand adds latency under load.

The mode should match the traffic pattern. A store with steady traffic benefits from workers being ready, while a low-traffic environment can use on demand to save memory.

Sizing pm.max_children

The most important PHP-FPM setting is pm.max_children, which caps how many requests run at once. Set too low, requests queue and the site feels slow under load; set too high, the workers can exhaust memory.

The sizing is a memory calculation: the available RAM divided by the average memory a worker uses gives a safe ceiling. Setting it beyond what memory supports is how a traffic spike turns into swapping and out-of-memory kills.

Memory limit and timeouts

PHP's memory_limit needs to be generous for Magento, especially for CLI operations like reindexing and compilation. The web and CLI limits are configured separately, and the CLI often needs a much higher value.

PHP-FPM's request_terminate_timeout caps how long a request can run before it is killed. Set correctly, it cuts loose truly stuck requests before they exhaust the worker pool, while allowing legitimate long operations to complete.

These two settings shape how PHP handles heavy and slow requests. A memory limit too low causes fatals, and a terminate timeout mismatched with the web server's causes confusing gateway errors.

The PHP-FPM slow log

PHP-FPM can log requests that exceed a duration, writing a stack trace for each. This slow log is one of the most useful diagnostics available, because it names the slow requests and the code they were running.

Enabling it with a sensible threshold captures the requests worth investigating without flooding the log. When memory fatals or timeouts recur, the slow log frequently catches the same requests and points at the expensive code.

It is a low-cost thing to have on. The slow log turns "some requests are slow" into a list of specific requests with stack traces to read.

JIT: usually not the win it sounds like

PHP 8 introduced a just-in-time compiler, and it sounds like it should speed up Magento. For a typical Magento web request, it usually does not.

JIT helps CPU-bound, compute-heavy code. Magento web requests are dominated by input and output: database queries, cache calls, and rendering, which JIT does little for, and in some cases enabling it adds overhead without benefit.

OPcache preloading

PHP 7.4 added OPcache preloading, which loads a set of files into memory once at startup so they are permanently ready. In principle this benefits a large application by keeping core code resident.

With Magento the benefit varies and it needs testing rather than blind adoption. It interacts with how the codebase is deployed and structured, so it is an advanced option to try and measure, not a default.

The fundamentals come first. A correctly sized OPcache with timestamp validation off delivers most of the available benefit before preloading is even considered.

PHP 8.4 and staying current

PHP 8.4 is supported on recent Magento, and staying on a current, supported PHP version matters for both performance and security. Newer PHP versions bring performance improvements of their own, on top of any tuning.

The catch is extension compatibility, as always. Moving to a newer PHP is a version-alignment exercise where every extension has to support the target, which is a separate check from tuning.

The order is: get onto a supported version with all extensions compatible, then tune that version for the store. Tuning an old or unsupported PHP is optimizing something you should be leaving.

The interned strings buffer

OPcache has a less-discussed setting worth tuning for Magento: the interned strings buffer. It stores repeated strings once in shared memory rather than duplicating them.

Magento's large codebase uses many repeated strings, so a larger opcache.interned_strings_buffer can help. It is a smaller lever than the main memory and file-count settings, but it fits the same pattern of sizing OPcache for a big application.

Like the others, it is a tune-and-measure setting. The OPcache status view shows interned strings usage, which tells you whether the buffer is sized appropriately.

Separate CLI and web configuration

PHP for the web and PHP for the command line are configured separately, and they have different needs. The CLI runs reindexing, compilation, and imports, which need a high memory limit and no execution time cap.

The web SAPI serves requests, where a lower memory limit and a real time cap are appropriate. Confusing the two, or tuning only one, leaves either heavy CLI jobs failing or web requests over-provisioned.

Confirm both configurations explicitly. A CLI memory limit set for the web, or the reverse, is a common cause of reindex failures or web requests that consume more than they should.

Realpath cache and file operations

Beyond the realpath cache size covered earlier, the broader point is that Magento does a lot of file operations. Anything that reduces filesystem work per request helps.

OPcache with timestamp validation off, a generous realpath cache, and fast storage together minimize the filesystem cost. On a store with a large codebase, these file-related optimizations compound.

This is why the file-related settings are grouped in importance with OPcache itself. They address the same underlying cost: Magento touching a great many files on every request.

A baseline to start from

Rather than tuning from scratch, start from a Magento-appropriate baseline and adjust. The key values to set generously are OPcache memory and file count, the realpath cache, the CLI memory limit, and a PHP-FPM worker count sized to your RAM.

From that baseline, the measurements tell you what to adjust. The baseline gets you most of the benefit; the measurement refines it to your specific store and traffic.

Retune after major changes

PHP tuning is not set once and forgotten. A codebase that grows with new extensions may need more OPcache files, and traffic growth may need more PHP-FPM workers.

Revisit the tuning after major changes: a big extension addition, a traffic increase, or a PHP version upgrade. The settings that fit the store last year may not fit it after it has grown.

This is the same discipline as the rest of the stack. The configuration should reflect the store as it is now, not as it was when the values were first set.

Keep PHP itself patched

Tuning and patching go together. A tuned PHP that is behind on security updates is fast and exposed, which is not the trade you want.

PHP releases security fixes on its own schedule, and a supported version receives them. Staying current on the PHP patch level is part of keeping the whole platform secure, alongside Magento's own patches.

This ties PHP tuning back to version alignment. The right foundation is a current, supported, patched PHP version, tuned for the store, not an old version tuned to run fast while missing security fixes.

Compiled code and OPcache together

Magento's own compilation and OPcache work in tandem. The setup:di:compile step generates interceptor and factory code ahead of time, and OPcache then caches that generated code as bytecode.

Both need to be in place for production performance. Compiled dependency injection avoids generating code at runtime, and OPcache avoids recompiling any of it, so the two together keep the code path fast.

This is why a deploy clears OPcache: the compiled code changed, and the cache must reflect it. The interaction is a reminder that PHP tuning and Magento's build steps are parts of the same performance story.

The PHP-FPM status page

PHP-FPM can expose a status endpoint that reports on the worker pool in real time. Enabling it shows how many workers are active, how many are idle, and whether the pool is hitting its ceiling.

This is the direct way to know whether pm.max_children is right. A pool that regularly reaches its maximum, with a queue building, is telling you it needs more workers or the requests need to be faster.

Reading the status under real load is how you size the pool on evidence. It turns the worker-count question from a guess into a measurement, the same as every other setting here.

Revalidation frequency

If timestamp validation is on, as it should be outside production, opcache.revalidate_freq controls how often OPcache checks files for changes. A higher value checks less often, reducing filesystem work at the cost of picking up changes more slowly.

In production, with validation off, this setting does not apply, which is the fastest configuration. In development, a low value picks up code changes quickly, which is what you want while working.

The setting is a reminder that development and production want opposite configurations here. Fast pickup of changes in development, and no checking at all in production.

Tuning for containers and the cloud

Containerized and cloud environments change how the settings are sized. A container has its own memory limit, and pm.max_children must be calculated against that limit, not the host's total RAM.

Getting this wrong is a common container mistake. A worker count sized for the host, running in a container with a fraction of that memory, leads straight to out-of-memory kills under load.

The calculation is the same, just against the container's real memory allocation. In autoscaling setups, the per-container tuning is what lets each instance run reliably within its limits.

When the defaults are actually fine

Not every setting needs changing. Many PHP defaults are reasonable, and the high-impact tuning for Magento is concentrated in a handful of settings.

OPcache memory and file count, timestamp validation, the realpath cache, PHP-FPM worker sizing, and the memory limits carry most of the benefit. Chasing obscure settings beyond those is usually effort spent for little return.

The discipline is to tune what measurably matters and leave the rest. A few settings sized correctly for Magento outperform a configuration file full of changes copied from elsewhere.

Measure the tuning

Every change here should be measured, not assumed. OPcache exposes a status view with its memory use and hit rate, PHP-FPM reports its pool status, and response times show whether the tuning helped.

Change one thing at a time and watch the numbers. An OPcache that stopped evicting, a PHP-FPM pool that no longer queues, and faster response times are the signals that a change worked.

Knowing that OPcache is sized correctly, that PHP-FPM matches your traffic and memory, and that you are on a current, supported PHP version is what turns the PHP layer from a default into a tuned foundation. That tuning is a standard, high-value part of a performance and infrastructure review.