OPcache Preloading - A miracle cure to improve PHP performance?

[00:02] even more performance out of your PHP application. There are only a few special cases where preloading will have a measurable impact on your application performance. And in this video, we are going to cover what preloading is, how

[00:17] you can set it up and configure it in your application and what performance gain you can expect. Mo, I'm Benjamin and living and breathing PHP performance for the last 10 years now, helping thousands of developers, companies, and

[00:32] open source projects to speed up their PHP code. Preloading is a core PHP feature since version 7.4 and was contributed by version 7.4 and was contributed by Dimmitri of Zent back in 2018

[00:46] and was accepted unanimously during voting. This feature allows you to preload scripts at the startup of the PHP process when no requests have run yet. Then each request run in the process has these preloaded functions

[01:00] and classes already available immediately as if they were internal classes. This is different than opcache itself which improves and eliminates the time spent compiling PHP scripts to bite code

[01:13] through caching. Preloading complements opcache by reducing time spent in the autoloader that may also take up a significant that may also take up a significant portion of your request time. So on

[01:27] paper, preloading should eliminate the time spent autoloading classes and reduce the response times in that share. The downside of pre-loading is that every startup of PHP FPM or Apache 2 is taking a longer time because the

[01:42] pre-loading script has to be compiled and run and put into memory. To use prerequisites. First, you have application has to be the only one running on the server. This is usually the case in modern PHP

[01:57] deployments, but I want to mention it regardless. Second, you must be using regardless. Second, you must be using PHP with uh either PHP FPM or Apache 2 PHP with uh either PHP FPM or Apache 2 with mod PHP or any other SARP that is

[02:10] shared nothing architecture-based preloading has no effect on application servers such as Franken Pip, Roadrunner or Laravel's Octane. And in runtimes such as breath on RVS Lambda, it may shift performance around only from the

[02:26] request to the boot time, but in a way that users will still feel and um recognize. The third requirement is that you uh write your own preloading PHP

[02:38] script. That script must essentially require all the files that you want to pre-ompile and preload into the PHP process. Uh the Symfony framework generates this by default. Um Laravel has for example a third party package

[02:54] that allows to do that which I haven't tested myself. Uh in other cases and when you don't use those two you have to write this yourself or find uh packages write this yourself or find uh packages that um do this for your f framework.

[03:09] The PHP documentation has information on how to do this uh in your application. uh in the pre-loading script any file reference by include include once and so on opache compile file will be passed into persistent memory in the following

[03:25] example all PHP files in the source directory will be preloaded unless they are a test file so we can see here uh a script iterating the source directory script iterating the source directory excluding test files and then require

[03:40] excluding test files and then require ones on the file and this does not take into account that um scripts might have dependencies on each other with um

[03:52] dependencies on each other with um either inheritance or um types uh used either inheritance or um types uh used for arguments and return types. So this order has to be the correct one to include because we don't have

[04:08] essentially have to do the mapping yourself which file comes first and which one comes after that and uh then you include them like in the right order. Then you have to configure the PHP ini with two settings opache uh

[04:25] preload points to the file that we've created before or our framework created and opach preload user um is the Linux user um that uh the

[04:38] process um switches into when running the scripts. After the change, just the scripts. After the change, just restart PHP FPM or Apache 2 and then restart PHP FPM or Apache 2 and then monitor your error lock files uh or your

[04:51] exception tracking software such as Tideways to make sure that everything runs smoothly. That's it. To see if opcache preloading is working, you can call opcache get status the

[05:05] you can call opcache get status the function in your uh code and look at the newly added preload statistics key that is only available when pre-loading is is only available when pre-loading is enabled. It includes a metric uh called

[05:18] memory consumption to understand how much memory the preloading stage um much memory the preloading stage um used. And uh I haven't looked at the PHP source code, but I would expect this memory to be taken from the regular

[05:32] memory to be taken from the regular upcache memory uh buffer and um counting towards this limit. In all honesty, I have not gotten around to test preloading on Tideways before, but it's hovering in my to-do list since it came

[05:46] out. This week, it was finally time to evaluate. The reason for not looking into it for the last five years is that I didn't expect the performance benefit to be large enough that it mattered looking into it and getting familiar

[06:00] with this feature. So let's look at a demo application and how much time it spends in autoloading and compiling. We can measure this with tightways which is hooking into two PHP engine level hooks available to PHP

[06:14] extensions. The first one is called Zen compile which is related to compiling PHP scripts and the second hook is called Zent autoload which is related to you would guess autoloading by overwriting uh and adding timing to

[06:31] both hooks in our typebased PHP extension. We can see how much time an application spends in both layers. At this time, there's no way to measure this in userland PHP code unless you directly patch the autoloader using

[06:46] highresolution timer calls. Let's take a look at a Shopware demo application look at a Shopware demo application which is written in Symfony uh to see what impact we can expect from autoloading in PHP scripts.

[07:00] So in the history module we can see the performance of layers over um large amount of time in this case 5 weeks and we can see autoloading here is around um

[07:14] 10 to 16 milliseconds on average in every request and this is across all these uh thousands of requests that uh were made um during that time.

[07:27] were made um during that time. And if we set this in relation to the 95 percentile of performance uh of the complete scripts then we can see with them being around 1 second the autoloading performance is actually

[07:42] below 1% share of the whole PHP request time and preloading only improves the autoloading time. So we don't expect this to be anything that improves

[07:54] visibly for users or makes the performance better in any significant way. But what if your application is already fast and takes less than 100 milliseconds to load? Let's take a look at the impact that preloading has on the

[08:08] Tideways back end. Because Tideways is based on Symfony and Symfony already generates a pre-loading script through the dependency injection container, my colleague Tobias and I could test the the impact of preloading with just 2

[08:22] hours of time investment. First, we started with an assessment of the potential impact that this uh preloading change could have on the performance of change could have on the performance of our data inest service. The data ingest

[08:35] our data inest service. The data ingest service um has a response time of around uh 19 milliseconds uh in the 95 percentile and the average is lower at around 12 uh milliseconds. We can see in the history of tideways

[08:50] We can see in the history of tideways that uh in the last five weeks the performance um that autoloading had the impact that autoloading had on this performance was always just 1 millisecond. So if we set this in

[09:04] relation we are expecting to see a 5 to 10% improvement by using uh op cache preloading. We rolled out this configuration change to our application servers and used

[09:17] to our application servers and used tideways to create a marker that allows us to compare the performance before and after this configuration change. We can see uh on this marker for the service for the data ingestion service

[09:33] service for the data ingestion service that the performance improved by 10% um going from 20 milliseconds to 18 milliseconds in the 95 percentile. So exactly what we um thought was possible um before. And um the requests here we

[09:50] um before. And um the requests here we can see at 32,000 per minute. We can can see at 32,000 per minute. We can also um see this by hovering over um the layer performance graph here where we can see that before the change

[10:02] autoloading is still responsible for 2 milliseconds of the performance and afterwards it's uh not responsible for the performance anymore.

[10:17] marker that we've added to the API service. The API service only has 4,000 requests every minute, so it's used a little less. Um, and the performance dropped from 34 milliseconds to 32 milliseconds. Still an improvement of

[10:33] milliseconds. Still an improvement of around 5% and that is uh very good for these kind of very fast requests. We have also tested this in our staging environment where you can see that before uh the configuration change

[10:47] autoloading um took about 7 or 8 milliseconds uh on average and after the milliseconds uh on average and after the change um it's not visible anymore and the performance dropped from 40 milliseconds to 30 milliseconds for a

[11:01] milliseconds to 30 milliseconds for a 25% improvement in performance. However, think that this is just our staging environment and it's uh limited in resources and also doesn't have a lot of requests. As you can see here, just six

[11:14] requests every minute. Uh so this improvement is not really um showing real world potential. While preloading does not improve performance in a way that users feel, it allows to handle more requests and increases throughput

[11:30] capacity for high traffic applications. Consequently, you should look into opcache preloading if your application is already very fast and has response times of below 100 milliseconds. This might allow you to save costs by

[11:43] reducing aggregated CPU count. With higher response times, I don't think preloading is actually worth it, but maybe there are other OPC cache settings that you haven't optimized yet. See this next video for details and don't forget

[11:58] to subscribe to the channel or our newsletter on PHP performance topics. newsletter on PHP performance topics. See you around.