PHP Benchmarks: 8.4 performance is steady compared to 8.3 and 8.2
Every year, like clockwork, a new version of PHP is released at the end of November.
Naturally, you want to know, how much performance gain is in this new release across common frameworks and applications?
Our tests show that, in general, the performance between 8.2, 8.3 and 8.4 does not move much for a Laravel, Symfony and WordPress demo application.
Upgrading to the latest PHP version is not a magic pill to improve performance.
Not all is gloomy though, in our PHP 8.4 Performance, Operations and Debugging post you find a few specific ideas how you can use new features to improve your performance, for example sprintf compile time optimizations, SHA-NI or Lazy Objects. However, these will only be useful when using the respective functionality and might require some work on your part to integrate.
The biggest lever for performance is the application architecture and the code you write. If you want to find out where to start optimizing your application code, Tideways, our production-ready profiling and monitoring, can help you detect areas for improvement.
To benchmark PHP, we have set up these popular PHP projects:
- Symfony with PHP 8.4, 8.3, and 8.2
- WordPress with PHP 8.4, 8.3, 8.2, and 7.4
- Laravel with PHP 8.4, 8.3, 8.2
Our intention is to give you a rough idea of how much performance is improved as a percentage by just updating the PHP version.
WordPress supports many PHP versions in parallel, so we use it as a good yardstick for performance changes from PHP 7 to 8.4.
Setup
The benchmarking is done under these conditions:
- Code and Infrastructure Provisioning: github.com/tideways/php-benchmarks
- Machine: Hetzner CCX 31 (8 dedicated vCores on EPYC 7003 or EPYC 9004)
- OS: Debian 12 („Bookworm“)
- Database:
- MySQL 8.4.4 for WordPress and Laravel
- SQLite 3 for Symfony
- PHP (all built by deb.sury.org): 7.4.33, 8.2.28, 8.3.20, 8.4.6
- JIT not enabled
- FPM with static pool and 17 workers.
- Projects: Laravel 12.3.0, Symfony 7.1.1, WordPress 6.7.2
- Vegeta v12.12.0
- HAProxy 3.0.9
You can find more on methodology after the results.
Results
Symfony
Upgrading just PHP 8.3 to 8.4 makes the Symfony demo application run with the same performance when simulating a fixed number of 100 requests/minute. Fluctuations are within the margin of error.
When run with 15 concurrent requests, the requests/seconds also do not vary significantly between PHP versions:
Laravel
Upgrading just PHP 8.3 to 8.4 shows no visible difference to response times of the Laravel demo application, except for a small improvement in the 99th percentile.
And the requests/seconds are close to each other as well.
In contrast to both Symfony and WordPress, we used our results for 5 concurrent users here and not 15, because for Laravel in particular the application was constrained by CPU scheduling with 15 concurrent users on just 8 cores and we didn’t want this effect to muddy the results.
WordPress
Similar with WordPress, upgrading from PHP 8.3 to 8.4 shows no significant change in response times. The comparison to PHP 7.4 does show that PHP 8 overall became slightly faster, though.
And again the requests/seconds are close to each other, with only PHP 7.4 showing a ~5% lower number.
❗With Tideways PHP Profiler, you can find bottlenecks in your application code by continuously profiling the production environment at low overhead. Get your free 14 -day trial to start optimizing.
More Notes on Methodology
With benchmarking, the results heavily rely on the assumptions and setup. There are a few changes we have made to other popular PHP benchmarks, and we want to discuss our methodology here.
We run the benchmarks in two modes:
- With fixed requests per second, with a focus on response times
- With a fixed level of concurrency, with a focus on requests per second.
Why do we not only report performance in requests per second? Other benchmarks often compare if a new PHP version can serve more requests per second. They do this by running as many requests as possible with a fixed number of concurrent threads that create new requests.
This provides synthetic or artificial comparisons because for real-world scenarios you would never run your PHP application at the limit of capacity and getting as many requests out as possible.
Instead, response time or time-to-first-byte (TTFB) under regular load is what you are interested in to understand how performance affects real users.
We don’t run the tests with very high concurrency because we want to make sure the numbers reflect PHP performance, not the operating system’s process scheduler, thus no CPU contention is happening.
PHP 8.4 vs 8.3 vs 8.2 Performance: Does every upgrade get faster?