[0:00] With every new release of PHP, you
[0:02] probably ask yourself, is there an
[0:04] automatic gain in performance just by
[0:07] upgrading? This is what I asked myself
[0:09] when PHP 8.4 came out and put my team at
[0:12] Tideways to work on a benchmark to
[0:14] answer once and for all. The results are
[0:17] now published on our blog, and I want to
[0:20] discuss them in this video. The main
[0:22] result, upgrading to PHP 8.4 four will
[0:26] not magically increase the performance
[0:28] of your PHP application to noticeably
[0:31] better
[0:32] levels. In fact, our benchmarks show
[0:35] that during the PHP8 series, not a
[0:38] single release improved the performance
[0:41] noticeably. That means PHP 8.4, 8.3, 8.2
[0:45] are almost virtually the same
[0:48] performance. This was quite a surprise
[0:50] to me. The reason is that previous
[0:53] benchmarks by others showed that there
[0:57] was a noticeable small improvement
[0:59] across uh the different
[1:02] versions. Specifically, this uh PHP
[1:05] benchmarks post that was widely cited
[1:08] across the community showed increases of
[1:12] a few% between uh the different PHP 8.1,
[1:16] 8.2, and 8.3 versions.
[1:18] In our benchmark, we were not able to
[1:20] replicate these improvements. For our
[1:23] benchmark, we set up two test scenarios
[1:25] that each ran for 60 seconds, including
[1:28] warm-up periods. First, we measured the
[1:31] response times by sending a fixed number
[1:35] of
[1:36] requests. Second, we measured the
[1:38] requests per second by sending as many
[1:41] requests as possible during the time
[1:43] period.
[1:45] We did this against three widely spread
[1:48] frameworks. A Symfony demo application,
[1:51] a Laravel demo application, and a
[1:53] WordPress demo application. You can find
[1:56] more details on our methodology on the
[1:58] blog post, including the code to set up
[2:00] the benchmarks, uh the specifications of
[2:03] the machine we used and the versions of
[2:06] all the different software that we
[2:07] benchmarked against. Let's look at the
[2:10] results starting with
[2:12] Symfony. As you can see, for the tests
[2:15] sending 100 requests per second, the
[2:18] response times across the versions PHP
[2:20] 8.2, 8.3, and 8.4 did not noticeably
[2:25] change. The average median 95, and 99
[2:29] percentile are virtually the same.
[2:31] Looking at the test with 15 concurrent
[2:34] users attempting to send as many
[2:36] requests as possible, we also see that
[2:38] for PHP 8.2, 8.3, and 8.4, for the
[2:42] number of requests is almost the same at
[2:47] 538. We see the similar results for the
[2:50] Laravel demo application across PHP 8.2
[2:53] to 8.4 for all the metrics average
[2:56] median 195 and 99 percentile. The
[3:00] response times are almost the same
[3:02] signaling that the performance did not
[3:04] really change for the test sending as
[3:07] many requests as possible for 60
[3:09] seconds. The Laravel demo application
[3:12] achieved around 1,020 requests per
[3:15] second regardless of the PHP version
[3:18] 8.2, 8.3 or 8.4. So the performance here
[3:22] again almost the
[3:26] same. We also picked WordPress because
[3:29] it's possible to install it on such a
[3:32] wide range of PHP versions that we are
[3:35] able to test it from PHP 7.4 to
[3:38] 8.4. Again, throughout the PHP8 series,
[3:42] there's not really a visible change in
[3:44] performance. However, from PHP 7.4, it
[3:48] seems the performance increased slightly
[3:51] to
[3:52] PHP8. We can see this here that the
[3:55] response times for 100 requests per
[3:57] second slightly decreased by a few
[4:00] milliseconds from uh PHP 7.4 to uh 8.2
[4:04] and following versions.
[4:09] This change is much more visible for the
[4:12] scenario where we send 15 concurrent
[4:15] users to uh perform as many requests as
[4:17] possible for 60 seconds. For PHP 7.4,
[4:21] the WordPress installation achieved 206
[4:25] requests per second and a 5% roughly 5%
[4:29] higher number for all the PHP 8.2, 8.3,
[4:33] and 8.4 four versions with around 220
[4:37] requests. This at least shows that there
[4:39] is some improvement from PHP 7 to PHP 8,
[4:43] but it also cements that the performance
[4:46] in P the PHP8 series really didn't
[4:49] change a lot just by upgrading the
[4:51] version. With these results, I ask
[4:54] myself what the future for PHP
[4:56] performance holds.
[4:58] First, the Zen virtual machine seems to
[5:00] be at the end of the potential
[5:02] improvements that we see. The next
[5:05] versions will not radically increase the
[5:07] performance anymore. Second, we can see
[5:11] improvements in specific PHP APIs across
[5:14] the latest versions. So, for example,
[5:17] the new DOM document HTML 5 support has
[5:20] a lot of performance improvements. We
[5:23] have the sprintf improvements and also
[5:25] improvements to various APIs and
[5:27] functions. So if you want to invest some
[5:30] time in your application, you can
[5:32] improve it the performance by using more
[5:35] modern and faster
[5:37] APIs. Third, we haven't really seen much
[5:41] performance improvements by the just in
[5:43] time compiler that uh PHP now has for
[5:46] web applications. the performance
[5:48] difference is really not measurable and
[5:50] we will see if there's maybe an
[5:52] improvement to the uh JIT in the future
[5:54] that will level up the performance of
[5:56] PHP to a new level. In conclusion, your
[6:00] application architecture, code, and
[6:02] algorithms are probably the most
[6:04] important puzzle piece in improving the
[6:07] performance of your application going
[6:09] forward. You can find a few ideas on how
[6:12] to improve PHP performance on this
[6:13] YouTube channel, and we'll add a new
[6:15] video every week. Don't miss out by
[6:18] subscribing to this channel. See you
[6:20] around. Bye.