PHP Server Optimization in 2026: PHP-FPM, OPcache, JIT and Profiling

PHP server optimization in 2026: PHP-FPM, OPcache, JIT and profiling

PHP launched in 1995 as a set of Perl CGI scripts for tracking page visitors. Thirty years later, it serves about 76% of the entire web (W3Techs, 2026) — from a single person running a WordPress blog to Slack, Wikipedia, and Etsy. No other language has come this far while preserving so much backward compatibility: code written in 2010 will, in the vast majority of cases, run on PHP 8.4 without changes.

What did change dramatically is how PHP runs on the server. In 2010 the standard was mod_php in Apache: one Apache process = one PHP interpreter, slow, RAM-hungry, but simple. In 2026 the standard is PHP-FPM with a dedicated worker pool, OPcache with precompiled bytecode in memory, and a JIT compiler generating machine instructions for hot code paths. Combined, this delivers 5–10× better performance than mod_php — but it requires tuning.

The problem is that apt packages ship PHP with conservative defaults — values chosen so it would run on a 512 MB VPS and on a 64 GB server alike. As a result, 90% of servers on the internet run with configs that don't match their hardware at all. This article is about fixing that — without academic theory, with concrete numbers and real examples for PHP 8.4 on Ubuntu 24.04 LTS.

Step one: finding what you actually need to edit

Before any optimization, you need to know exactly which PHP configuration files your server is reading. On Ubuntu, several versions can live side by side (PHP 8.1, 8.2, 8.3, 8.4 install in parallel), and more often than not your changes end up in the wrong place.

Commands that give a definitive answer

php -r 'echo php_ini_loaded_file() . PHP_EOL;'
# Prints the path to the main php.ini for CLI

php-fpm8.4 -i | grep "Loaded Configuration"
# Path to php.ini for FPM (usually /etc/php/8.4/fpm/php.ini)

php -r 'echo phpversion() . PHP_EOL;'
# PHP version used by CLI

systemctl status php8.4-fpm
# Whether the FPM service is running and which version

PHP directory layout on Ubuntu

If you're on a different PHP version, substitute its number for 8.4. On older Ubuntu (18.04, 20.04) the paths may start with /etc/php5 or /etc/php/7.x.

PHP-FPM Pool: the key to handling load

The FPM pool is how many concurrent PHP processes the server can serve. Set wrong, the site either "falls over" from a worker shortage or "kills" the server through RAM exhaustion. This is the single most important config for performance — and the one where the biggest mistakes are made.

Three modes: dynamic / static / ondemand

How to calculate pm.max_children

This is the number that affects stability most. The formula:

pm.max_children = (Total RAM − RAM used by the system) / Average RAM per PHP process

In practice, one PHP process running WordPress with a typical plugin set eats 50–80 MB of RAM while processing a request. For Laravel apps — 80–120 MB. Magento 2 — 200–300 MB. To measure precisely:

ps -ylC php-fpm8.4 --sort:rss | awk '{sum+=$8; count++} END {print "Average:", sum/count/1024, "MB"}'

Example calculations for typical servers

Optimal pool config for dynamic mode

File /etc/php/8.4/fpm/pool.d/www.conf:

; Basic pool settings
pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500

; Slow log — records requests slower than 5 seconds
slowlog = /var/log/php8.4-fpm-slow.log
request_slowlog_timeout = 5s

; Status page for monitoring — view from 127.0.0.1
pm.status_path = /fpm-status
ping.path = /fpm-ping

Slow log — an underrated tool

The request_slowlog_timeout setting tells FPM to log a trace of any request that takes longer than the specified time. This lets you find bottlenecks without installing complex profilers. A typical slow log entry:

[03-Jun-2026 14:23:15] [pool www] pid 12453
script_filename = /var/www/site/wp-cron.php
[0x00007f5e2c4a8e30] curl_exec() /var/www/site/wp-includes/class-wp-http-curl.php:155
[0x00007f5e2c4a8e30] request() /var/www/site/wp-includes/class-wp-http.php:413

It's immediately clear: the request is stuck on curl_exec() in wp-cron — most likely a plugin trying to reach an external API that isn't responding. Without slow log, this problem would stay invisible.

OPcache: one number that changes everything

OPcache is PHP's built-in bytecode cache. Without it, PHP rereads every .php file from disk on every request, parses it into bytecode, and only then executes it. With OPcache enabled, the bytecode is stored in RAM, and repeat calls to the same file read the already-compiled version.

This gives a 3–5× speedup for any PHP application without changing a single line of code. It's not a theoretical figure — it's a real difference visible on any profiler.

Check whether OPcache is enabled

php -r 'echo opcache_get_status() ? "OPcache: ON" : "OPcache: OFF"; echo PHP_EOL;'

If it's OFF — enable it. On Ubuntu the package is called php8.4-opcache (usually installed by default but disabled in the config).

A working OPcache config for production

File /etc/php/8.4/mods-available/opcache.ini:

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=2
opcache.validate_timestamps=1
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.jit=tracing
opcache.jit_buffer_size=128M

What each parameter means

An important nuance: validate_timestamps=0 in production

This is the most controversial parameter. If you set validate_timestamps=0, PHP stops checking for file changes — and any code update must be accompanied by manual OPcache clearing (php8.4-fpm reload or opcache_reset()). In exchange, performance rises another 5–10%, because there are no stat() system calls on each request.

Worth it? Depends on the deployment process. If you have a CI/CD pipeline that auto-reloads FPM after release — yes, definitely. If you update the site via FTP by hand and forget to restart the service — better to keep validate_timestamps=1.

JIT compiler: when to enable and when NOT to

JIT (Just-In-Time compiler) arrived in PHP 8.0 and compiles "hot" code into native CPU instructions, bypassing the interpreter. Sounds like a speedup magic wand, but in practice it's more interesting than that.

Where JIT actually helps

• CPU-bound computations: image rendering, cryptography, parsing large data structures, mathematical algorithms. Here JIT can deliver a 1.5–3× speedup.
• CLI scripts: long data-processing jobs, background calculations, scientific work.

Where JIT doesn't help, and sometimes hurts

• Typical web apps (WordPress, Drupal, Laravel): they are I/O-bound (most of the time is spent waiting on DB queries, file reads, API responses). The JIT speedup is in the 1–3% range, often invisible against normal variance.
• Sites with segfaults: JIT in some cases conflicts with third-party extensions. If worker crashes appear in the logs after enabling — that's the first hypothesis.

JIT configuration

JIT is controlled by two parameters in opcache.ini:

opcache.jit=tracing
opcache.jit_buffer_size=128M

Recommendation: enable tracing, measure performance before and after, keep it on only if the difference is noticeable. On a site with a typical CMS workload, JIT may just eat 128 MB of RAM and give nothing in exchange.

How to measure the effect of JIT

The simplest way is two tools together: Apache Bench for a load test and monitoring via top:

# Test without JIT (first disable JIT and reload FPM)
ab -n 1000 -c 10 https://yoursite.com/

# Test with JIT (enable it, reload FPM)
ab -n 1000 -c 10 https://yoursite.com/

# Compare "Requests per second" and "Time per request"

If the difference is under 5%, JIT is economically pointless for your case — you can disable it and return 128 MB of RAM to the system.

Realpath cache: a small parameter that saves your SSD

A parameter that's rarely discussed but has a disproportionately large effect on sites with lots of files (WordPress with 50+ plugins, Magento, large Laravel projects).

Every time PHP includes a file via require or include, it resolves the path through a series of stat() system calls. For a relative path like ../vendor/symfony/finder/Finder.php, that means several dozen calls to the filesystem. The realpath cache stores already-resolved paths in memory.

realpath_cache configuration

In php.ini:

realpath_cache_size = 4096K
realpath_cache_ttl = 600

The default is 256K — enough for about 150 cached paths. For WordPress with a reasonable plugin set you need at least 2–4 MB. Check current usage:

php -r 'echo realpath_cache_size() / 1024 . " KB used\n";'
# How many bytes the cache actually uses at this moment

php -r 'print_r(realpath_cache_get());'
# A full list of all cached paths (useful for diagnostics)

If the number from the first command is close to the realpath_cache_size value in php.ini — the cache is overflowing, raise the limit.

Profiling: finding what's actually slow

Up to this point we've been tuning by guessing: bumped OPcache, bumped the pool, enabled JIT. But real optimization begins when you see exactly where the code spends time. Without profiling, you're not tuning your site — you're tuning an abstract "average site".

Tools, in order of complexity

Where to start: OPcache GUI

OPcache GUI is a small .php script that shows detailed cache-usage statistics. Installs in a minute:

cd /var/www/site/
wget https://raw.githubusercontent.com/amnuts/opcache-gui/master/index.php -O opcache-status.php

Then open https://yoursite.com/opcache-status.php in a browser — you'll see memory usage, hit ratio, the number of cached files, and a list of what's in the cache. If the hit ratio is below 99% — that's a signal that memory_consumption is too low.

Xdebug profiler — fine-grained profiling

Xdebug is the best-known PHP debugger and profiler. For profiling, it's used in profile mode:

; In /etc/php/8.4/mods-available/xdebug.ini
xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug
xdebug.start_with_request = trigger

Then add ?XDEBUG_TRIGGER=1 to the URL — Xdebug will write a call profile to /tmp/xdebug. Open the resulting cachegrind.out file in KCachegrind or QCachegrind — you'll see a call hierarchy with times, percentages, and call counts.

PHP-specific security: what other articles don't cover

General server security (HTTPS, fail2ban, security headers) is covered in detail in our article on protecting your site from hackers. Here — strictly the PHP level: php.ini parameters that close PHP-specific attack vectors.

expose_php = Off

By default PHP adds an X-Powered-By: PHP/8.4.X header to every response. That's free intel for an attacker: they know your exact version and can hunt for matching CVEs. Disabling it is simple:

expose_php = Off

Verify after an FPM restart:

curl -I https://yoursite.com/ | grep -i powered
# If nothing prints — the header is gone

disable_functions: what's actually worth disabling

This is a list of PHP functions that will never execute. If a plugin or vulnerability tries to escape to a shell through them, PHP just throws an error. A sensible minimum for most sites:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source,phpinfo

open_basedir: isolating PHP from the filesystem

This parameter restricts which directories a PHP script can access. Even if an attacker uploads a shell to /uploads, they won't be able to read /etc/passwd or /var/log through it:

open_basedir = /var/www/yoursite/:/tmp/

Everything outside those directories becomes unreachable to functions like file_get_contents, fopen, include. One of the strongest PHP-level protections — and one that often gets skipped.

allow_url_fopen = Off (where possible)

By default PHP allows opening URLs the same way as files: file_get_contents('https://...'). An attacker can use this for:

• SSRF (Server-Side Request Forgery) — force the server to make requests to internal resources
• Remote File Inclusion — include malicious PHP code from an external server

If your code doesn't access external URLs via file_get_contents (and instead uses cURL or Guzzle, as is standard in modern applications) — disable it:

allow_url_fopen = Off
allow_url_include = Off

allow_url_include should always be disabled — it's a dedicated vector for Remote File Inclusion and in 99% of cases nobody needs it.

session.cookie_httponly, session.cookie_secure

PHP session settings. Without them, JavaScript on the page can read the session cookie (via an XSS vulnerability, for example), or the session cookie may be transmitted over HTTP bypassing HTTPS:

session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = "Strict"
session.use_strict_mode = 1

Top configuration mistakes I see on other people's servers

1. memory_limit = -1 "just in case". That means "no limit". A single runaway script can eat all the server's RAM. It should be a specific number: 256M, 512M, 1024M.
2. max_execution_time = 0. Same idea — a script with no timeout can hang for hours, holding an FPM worker. 60–90 seconds is a normal range for most sites.
3. display_errors = On in production. Errors get shown to users in the browser, along with file paths, library versions, and sometimes SQL fragments. Show them only on a dev server. In production — display_errors = Off, log_errors = On.
4. pm.max_children picked blindly. Either set to 5 and the site falls over on the first traffic spike, or set to 200 and the server chokes. Calculate it with the formula from the FPM section.
5. OPcache with memory_consumption=64. The default value from most tutorials. For any real CMS site that's too little — the cache constantly overflows and resets. Minimum 128, realistically 256–512.
6. opcache.validate_timestamps=0 without CI/CD. After deployment the site shows the old code, and admins desperately hunt for bugs. Either set it to 1, or configure automatic FPM reload after release.
7. JIT with buffer_size=512M because "more = better". On a CMS site that swallows half a gig of RAM for nothing. JIT only uses what it actually needs — start with 64–128M.
8. info.php / phpinfo.php left in production. A temporary file made for a check that got forgotten. An attacker sees the PHP version, all loaded modules, paths, environment variables. Delete it right after checking — we covered the danger of exposing software versions and how to hide them in our article on checking the Apache version.

Frequently asked questions