Compatibility with/take advantage of code preloading in PHP 7.4

Open on Drupal.org →

Created on 24 January 2020, almost 5 years ago

Updated 19 September 2024, 3 months ago

PHP 7.4 ships with opcache preloading - https://wiki.php.net/rfc/preload - which allows a framework to specify a preload file which will:

...load a certain set of PHP files into memory - and make their contents “permanently available” to all subsequent requests that will be served by that server.

All the functions and classes defined in these files will be available to requests out of the box, exactly like internal entities (e.g. strlen() or Exception). In this way, we may preload entire or partial frameworks, and even the entire application class library. It will also allow for introducing “built-in” functions that will be written in PHP (similar to HHVM's sytemlib).

Notably, this comes with some drawbacks that may not make preloading advisable/possible in certain environments (e.g. shared servers) but is well suited for more "modern" runtime environments such as containers, which generally map to 1 "server" (container) per codebase.

The traded-in flexibility would include the inability to update these files once the server has been started (updating these files on the filesystem will not do anything; A server restart will be required to apply the changes); And also, this approach will not be compatible with servers that host multiple applications, or multiple versions of applications - that would have different implementations for certain classes with the same name - if such classes are preloaded from the codebase of one app, it will conflict with loading the different class implementation from the other app(s).

Akin to Symfony 4.4's compatibility: https://symfony.com/blog/new-in-symfony-4-4-preloading-symfony-applicati...

The proposal would therefore be to ship a preload file which may be optionally included in the site's php ini configuration set; this would be a default-OFF (since it requires manual intervention in the hosting environment) and opt-in ON situation.

As Drupal has much of its core imported from Symfony and already boasts an extensions API, I would imagine extending Symfony's model would be a starting point.

✨ Feature request

Status

Active

Version

11.0 🔥

Component

Last updated 5 days ago

No maintainer

Created by

🇺🇸United States bradjones1 Digital Nomad Life

Live updates comments and jobs are added and updated live.

Performance
It affects performance. It is often combined with the Needs profiling tag.

scalability

PHP 7.4
The issue particularly affects sites running on PHP version 7.4.0 or later.

Incomplete comments

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment over 1 year ago →
🇫🇷France andypost
It should help running tests a lot for new CI 📌 [PP-2] Speed up gitlab ci runs Postponed
Comment about 1 year ago →
🇫🇷France andypost
In PHP 8.4 new JIT engine coming https://github.com/php/php-src/pull/12079

PS: using opcache.jit_buffer_size=20M mostly all Drupal sites for last half year without issues but no preloading in a wild(
Comment 3 months ago →
🇷🇺Russia Chi
I just created one more generator for preload script.
https://www.drupal.org/project/opc →

However, while profiling my project I found another way to optimize opcache.
There are a couple opcache settings which default values are not suitable for production.

opcache.validate_timestamps=1 opcache.revalidate_freq=2
A typical Drupal sites loads about 1k - 2k files per request. With above configuration it'll revalidate opcache every 2 seconds.

Turning off opcache.validate_timestamps gave me almost same speed boost as preloading. I think, as long as you don't edit code on production that setting can be disabled. The invalidation should happen through php-fpm reload on deployment.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024