There is this fantastic new feature in php 7.4 called preloading that appears to dramatically speed up performance.
“Using preloading without any code modification I got ~30% speed-up on ZF1_HelloWorld (3620 req/sec vs 2650 req/sec) and ~50% on ZF2Test (1300 req/sec vs 670 req/sec) reference applications. However, real world gains will depend on the ratio between the bootstrap overhead of the code and the runtime of the code, and will likely be lower”.
I’m not sure if we have a performance rig already for yii. But if yes it would firstly be interesting to see how we perform and secondly would be a great way to learn about preloading. There is bound to be best coding practises to get the most out of it. In which case we implement during the year getting ready for php 7.4 in Dec.
Who knows, maybe we could grab some headlines as one of the first optimised preloading frameworks out there
What kind of optimizations from framework side you’re expecting? Preloading helps for apps which uses a lot of classes (you can skip autoloading all of them and lower memory consumption), there is not much to do to make preloading work better.
Preloading is somewhat over-excited here.
It basically removes first-request overhead, nothing more.
It was designed mainly to alleviate e.g. server restart on large hosting services when high traffic might kill server.
Yii tries to minimize memory footprint so mostly one may barely note that something was “preloaded”.
Enabling is related mainly to php.ini config (for sysadmins, should not be controlled on framework level) and also note some possible issues related to preloading (e.g. modified file).
It’s a nice feature but I don’t see much to do about it in this case.
I’m a bit out of depth here so please excuse any noob stuff. But Isnt preloading in this case dealing with the opcache. The RFC states …
"While storing files in an opcode cache eliminates the compilation overhead – there is still cost associated with fetching a file from the cache and into a specific request’s context. We still have to check if the source file was modified, copy certain parts of classes and functions from the shared memory cache to the process memory, etc. Notably, since each PHP file is compiled and cached completely independently from any other file, we can’t resolve dependencies between classes stored in different files when we store the files in the opcode cache, and have to re-link the class dependencies at run-time on each request. "
Now again I’m a bit out of my depth here but if its true that each request is performing disk operations even though its compiled classes in opcache then eliminating that would surely help.
I’m guessing that the ZF prefix used in the performance test is quoted in the RFC is Zend which I believe is very heavy class wise so the guys test case result might be skewed. But if not it would certainly be interesting to see what happens for us
Nope. It is exactly opposite, since preload script (which should preload all classes which may be used in all further requests) is executed on server start, so it makes restart even heavier. But thanks to this you can skip autoloader overhead (and some low-level opcache memory operations) and this will affect all requests, not only the first one.
I’m still not sure what framework could improve and document in this matter - preloading guidelines will be similar (if not the same) for all apps, regardless of used framework.
If I understand correctly, this preloading feature of PHP 7.4 will benefit all the users of PHP. Not only the future users of Yii 3 but also the current users of Yii 2 and other frameworks out there. All that is needed is a simple documentation how to preload the framework code into the PHP memory space. And when the application get fairly mature, it will be great to preload the app code along with the framework code altogether.
