PHP 7.4 preload

Hey Kevin B.!

Thanks for posting this :). My guess is that this might only be needed if your fpm is running as root... but I'm not sure - the docs seem to suggest that (I'm thinking between the lines: if your fpm is running as root, then that might be who would do preloading... but then that's not allowed):

> Preloading code as root is not allowed for security reasons. This directive facilitates to let the preloading to be run as another user

Regardless, at the very least, many users will need this, so we'll add a note :).

Thanks!

Hey Donjedi!

Good questions :).

First: how does Symfony decide which files to preload? This is decided on a system-by-system basis. Internally, there is a "cache warmer" system. This is a system that runs if you execute cache:warmup, which you normally should do as part of a deploy. Anyways, this system predates preloading by many years and its job (apologies if you're already aware) is to create as much of the cache as possible - e.g. converting the Twig templates to their cached version, parsing and caching many annotations, routing, etc. When preloading was added, the cache warmers got a second job: during their warmup process, they can return an array of classes that should be preloaded. Any bundle can add a "cache warmer", so each bundle is basically deciding which classes *it* thinks are important enough to preload. An example is the RouteCacheWarmer - https://github.com/symfony/... - which actually just calls the Router itself - https://github.com/symfony/... - and that returns the generator and matcher classes.

Additionally, each "bundle" class is added to the preload automatically. That, in itself, isn't that important, but bundles can use that to notify the preload system of other important classes that should be included - e.g. https://github.com/symfony/...

In *addition* to that, there is also something called the "hot path" in Symfony, which are classes that are determined to basically be *always* needed, like the event dispatcher. These also become part of preloading, in addition to any dependent services that these have.

So... all of this is determined internally, and it's quite complex to get a balance of what's "just right" for most setups.

Second, how can you control this process and add your own stuff? Since Symfony 5.1, there's a tag for that! container.preload - https://symfony.com/blog/ne...

Let me know if you have any more questions - it's a great system, but it is complex internally :).

Cheers!

Thank you Ryan.
Great answer and explaining!

Hey picks

As I know it's impossible to make opcache.preload work with many symfony projects on one server. This feature is low level, and it works on per server basis. So you can run only 1 Symfony project on host where proload configured (I guess you even can run only 1 project at all with preload configured, no matter what project it is).

Cheers!

Hi sadikoff thanks for your answer. This is sad :/

Yeah! I had same thoughts. But this is reality for now, probably something will change in future!

Hey sherif807,

Unfortunately, I haven't heard about Dokku, so don't know, sorry! Try to search in their docs, or probably ask their support if they have one. Also, this kind of questions might be answered on StackOverflow, would be good to check I think.

Cheers