Repository navigation
Let OPcache cache files written after startup with BREF_LOOP_MAX - #2233
Open
aran112000 wants to merge 1 commit into
Open
aran112000 wants to merge 1 commit into
aran112000 wants to merge 1 commit into
Conversation
OPcache doesn't cache a file modified less than 2 seconds before the request started (opcache.file_update_protection). In the CLI, the request starts with the process, so with BREF_LOOP_MAX every PHP file written after startup (e.g. views compiled in /tmp) was compiled again on every include.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2232, which has a reproduction and measurements.
With
BREF_LOOP_MAX, OPcache never caches PHP files written after the process started (e.g. Blade views compiled in/tmp), so they are compiled again on every include.This sets
opcache.file_update_protection=0at the start of the function runtime whenBREF_LOOP_MAXis above 1, unless it's set inphp.ini. Only0works: any other value counts from the process start, so a file written later is always "too new".The protection is there to avoid caching a file that is still being written. In a long-running process, the file is written by the same process before it's included. Symfony's
PhpFilesAdapteralready works around this protection by dating its files 10 seconds before the request start.One side effect: OPcache compares mtimes to the second, so a cached file rewritten within the same second isn't seen as changed, and with the default file cache the old version stays in
/tmpuntil the file changes again. With the shared memory cache and the defaultrevalidate_freq, a long-running process already never revalidates files (revalidate_freqalso counts from the request start), so files written after startup now behave like the others. Compiled views and containers are written once, which is why I kept this toBREF_LOOP_MAXrather than the layers'php.ini.The new test fails without the change. I also checked that with
ini_set()at startup, a file written later is cached inbref/arm-php-85:3.