PHP 8.4 vs 8.3 on a VPS: OPcache, JIT, and Real Throughput Benchmarks

PHP 8.4 shipped in November 2024 and is now the default on Ubuntu 24.04 repositories and most 2026 managed images. The question for anyone running a small VPS is concrete: does upgrading actually buy throughput, and does the JIT compiler finally do something useful for web workloads? We ran the same WordPress 6.7 install, the same database dump, and the same load profile across both versions on identical hardware to get numbers rather than opinions.

Test Environment

Component	Specification
Instance	2 vCPU (shared, EPYC 9004 class), 4 GB RAM
Storage	80 GB NVMe local, ext4, noatime
OS	Ubuntu 24.04.3 LTS, kernel 6.8
Web server	nginx 1.26.2, worker_processes 2
PHP	8.3.14 vs 8.4.11, php-fpm, static pool of 8 workers
OPcache	256 MB, validate_timestamps=0, 16k files
Database	MariaDB 11.4, 12 MB dataset, buffer pool 768 MB
Application	WordPress 6.7 + WooCommerce 9.3, Redis object cache on
Load generator	wrk2, 4 threads, 100 connections, 3-minute runs, 3 repetitions

Both configurations ran on the same host, in the same hour, with the same Redis instance flushed between runs. The load generator ran from a separate VPS on the same provider to remove loopback from the measurement.

Raw Throughput

Scenario	PHP 8.3 rps	PHP 8.4 rps	Change	p99 8.3 / 8.4
Cached homepage (Redis + FastCGI cache)	4,180	4,610	+10.3%	12 ms / 11 ms
Uncached homepage (full PHP render)	112	131	+17.0%	410 ms / 342 ms
Product archive, 24 items, DB reads	87	99	+13.8%	520 ms / 448 ms
Cart + session write (Redis)	203	228	+12.3%	180 ms / 155 ms
Admin-ajax polling endpoint	640	735	+14.8%	48 ms / 41 ms

The uncached path gains most, which matches the theory: 8.4 includes targeted optimisations to array handling, str_* functions, and the inheritance mechanism, all of which sit squarely in framework bootstrap code. Cached responses are bounded by nginx, so the win is limited to the small amount of PHP still executing.

Does the JIT Help Web Workloads?

Short answer: barely, and it can hurt. We ran the uncached homepage with opcache.jit=tracing and jit_buffer_size=128M:

Configuration	rps	Peak RSS per worker
8.4, no JIT	131	48 MB
8.4, tracing JIT (128 MB buffer)	134	71 MB
8.4, function JIT	129	62 MB

A 2 percent gain for 23 MB of extra per-worker memory is a bad trade on a 4 GB box running 8 workers — that is 184 MB returned to the page cache for a rounding error in throughput. The JIT pays off for long-running computation (image processing, large loop-heavy jobs such as WP-CLI imports or report generation). Keep it off for the FPM pool serving web requests; if you need it, run it in a dedicated CLI process.

Memory and Stability

• Baseline RSS per worker: 44 MB on 8.3, 46 MB on 8.4 — effectively unchanged.
• Compile time from cold: 8.4 built the 1,840-file opcache in 9.2 s versus 10.1 s on 8.3, so the post-reload warmup window is shorter.
• Deprecations: WooCommerce 9.3 and WordPress 6.7 ran clean. Older plugins using implicit nullable parameter types will now emit deprecation notices — harmless to users, but noisy in debug.log.

If your workers are already near the memory limit, verify the arithmetic before adding a new PHP release on top; the process described in optimising PHP-FPM on a low-memory VPS applies unchanged, and the real-world headroom is set by your instance size. Compare what each tier provides on our VPS plans and hardware specification pages — on a 1 GB instance the extra JIT buffer alone would be the difference between a working pool and an OOM kill.

Upgrade Recommendation

• Upgrade if you are on 8.2 or older, or if you run uncached dynamic pages at volume. A 12–17 percent throughput gain for a package upgrade is close to free.
• Skip the JIT for web requests. Measure with it off, then try it on; the numbers above suggest it will not move your p95.
• Test plugin compatibility in staging first. Deprecation notices are cosmetic, but a plugin suppressing PHP 8.4 strict warnings can still break an admin page.
• Rebuild opcache on deploy. With validate_timestamps=0 you must reload FPM or your new code will not be served.

The measurement method here is the point. Reproduce it on your own instance with your own traffic profile before trusting any published benchmark, including this one.