Lack of interest Provide a preload.php file to be used with PHP 7.4+ opcache.preload directive

[Mouth]

PHP 7.4+ provides a php script preloading function with the opcache.preload directive.
It requires a file, preload.php is commonly used, to provide a list of the php files to preload.

From https://www.php.net/manual/en/opcache.preloading.php ...
"PHP can be configured to preload scripts into the opcache when the engine starts [...] and load code into persistent memory"
... thus XF php code will remain in memory, instead of having to be processed and loaded each time it's called. Much faster and efficient.

I'd like to see XF provide a preload.php within installation files, listing all the appropriate files in the src/ tree that would benefit with preloading. Admin's wanting to utilise this functionality, can reference the preload.php in their PHP configuration if they desire.

Further from https://www.php.net/manual/en/opcache.preloading.php ...
"It also requires restarting the PHP process to clear pre-loaded scripts"

XF should check for opcache.preload being active when running upgrades and installs (web or cli), outputting a reminder for the admin to restart php.

 

[Kirby]

Support for preloading would be nice, but I don't see this happening anytime (soon) as it would be pretty complicated if this should work without limiting what can be done via ACP.

Right now if you want to use preloading, you can't

• Install Add-ons via ZIP
• Upgrade Add-ons from ACP
• Uninstall Add-ons from ACP
• Enable Add-ons from ACP
• Disable Add-ons from ACP
• Disable extensions (class extensions and event listeners) via config.php
• Modify class extensions (enable, disable, add, remove, change execution order, etc.) via ACP

Some of those (like enabled/disabling Add-ons) would partly work (but require a PHP reload afterwards) while others (like upgrading an Add-on) would not work at all.

If you accept those limitations, do not run multiple PHP-FPM pools (there can only be one preload per PHP-FPM master process, not per pool) and do not care for templates/phrases being preloaded adding preload support would be fairly easy.

 

[Mouth]

Right now if you want to use preloading, you can't

• Install Add-ons via ZIP
• Upgrade Add-ons from ACP
• Uninstall Add-ons from ACP
• Enable Add-ons from ACP
• Disable Add-ons from ACP

Why?
I'd expect XF to only provide core XF php files within the preload.php files list. I wasn't suggesting add-on php files be included.

If you accept those limitations

I suggest an admin wanting to get the benefit from preloading would be happy. I already use cli cmd.php for XF upgrades (and add-on actions), so a php restart afterwards would not be a concern.

 

[Kirby]

Why?
I'd expect XF to only provide core XF php files within the preload.php files list. I wasn't suggesting add-on php files be included.

You didn't state that you only want to preload core files:

I'd like to see XF provide a preload.php within installation files, listing all the appropriate files in the src/ tree that would benefit with preloading.

Often used extensions classes would benefit from preloading, if Add-on files were excluded things would definitly get easier and the a/m limitations would not apply.

I suggest an admin wanting to get the benefit from preloading would be happy.

Sure I just think there wouldn't be many customers that would actually (be able to) use that.

 

[Mouth]

You didn't state that you only want to preload core files:

I'd like to see XF provide a preload.php within installation files, listing all the appropriate files in the src/ tree that would benefit with preloading.

I think that's fairly implicit. XF isn't going to provide a preload.php file within installation files that also lists every add-on's php files.

 

[Mouth]

Sure I just think there wouldn't be many customers that would actually (be able to) use that.

ACP (and cli cmd.php) upgrade could check for the opcache.preload being active, and if so remind admins to restart php for the upgrade to finalise. I think the majority(all?) server control panels have php restart functions, if the admin doesn't have root/shell access.

The performance benefit from preloading certainly outweighs having to restart php every 2 months or so (approx. XF release cycle)

 

[Kirby]

I think the majority(all?) server control panels have php restart functions, if the admin doesn't have root/shell access.

I don't use control panels, so I can't really comment on that.
Do they also support running multiple PHP-FPM master processes (of the same version) out of the box, eg. one master process per pool?

If not it would be pretty problematic to use preload if there are multiple XF pools (might even cause problems with other pools if vendor classes are preloaded).

Anyway, I am not at all against this suggestion, I just think it is complicated