{"id":1181,"date":"2026-09-19T23:08:49","date_gmt":"2026-09-19T23:08:49","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1181"},"modified":"2026-09-19T23:08:49","modified_gmt":"2026-09-19T23:08:49","slug":"php-8-4-vs-8-3-opcache-jit-vps-benchmark","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/php-8-4-vs-8-3-opcache-jit-vps-benchmark\/","title":{"rendered":"PHP 8.4 vs 8.3 on a VPS: OPcache, JIT, and Real Throughput Benchmarks"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

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

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.<\/p>\n\n\n\n

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

The uncached path gains most, which matches the theory: 8.4 includes targeted optimisations to array handling, str_*<\/code> 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.<\/p>\n\n\n\n

Does the JIT Help Web Workloads?<\/h2>\n\n\n\n

Short answer: barely, and it can hurt. We ran the uncached homepage with opcache.jit=tracing<\/code> and jit_buffer_size=128M<\/code>:<\/p>\n\n\n\n

Configuration<\/th>rps<\/th>Peak RSS per worker<\/th><\/tr><\/thead>
8.4, no JIT<\/td>131<\/td>48 MB<\/td><\/tr>
8.4, tracing JIT (128 MB buffer)<\/td>134<\/td>71 MB<\/td><\/tr>
8.4, function JIT<\/td>129<\/td>62 MB<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

Memory and Stability<\/h2>\n\n\n\n