Edit report at https://bugs.php.net/bug.php?id=71749&edit=1
ID: 71749
User updated by: iquito at gmx dot net
Reported by: iquito at gmx dot net
Summary: file_cache_consistency_checks has no effect
Status: Open
Type: Bug
Package: opcache
PHP Version: 7.0.4
Block user comment: N
Private report: N
New Comment:
I actually measured the impact of opcache.validate_timestamps - each time it triggers, my
application is about 10ms slower, which in my application means between 35% and 100% slower than
usual. That is a big impact, and I feel it is unnecessary. Me telling PHP when something has changed
seems much more sensible than PHP checking itself if something has changed, because I can tell PHP
exactly when it should check for changes.
I am sure there are better deployment models than mine - but the one I use actually works really
well for me: If the whole application is in the opcache, I can exchange the whole application while
PHP-FPM continues to run, and only when I tell PHP to reload the cache the whole application is
replaced. Even with 100+ requests per second and a lot of concurrency I never had a single
error/failure/problem in years with this kind of deployment, so it seems sound to me.
Giving a developer the chance to decide for himself when a cache should be rechecked, and having
different options to do so, would just lead to more use cases where something like a file_cache can
be used and can lead to new solutions. I am a big fan of opcache, and I think the file_cache is a
great idea, but without more options to influence how memory opcache and file_cache interact and
when file_cache should be "reset"/rechecked some solutions to existing problems are just
not possible - for example my usage, but maybe also others. My suggestions are maybe not even really
good, I am sure there are many possibilities for sensible and flexible settings.
Previous Comments:
------------------------------------------------------------------------
[2016-03-10 03:48:43] rasmus@php.net
I think you are overestimating the performance impact of opcache.validate_timestamps, Set your
frequency high enough and I challenge you to measure any impact. And when it comes to deploying new
code, the fact that you don't need to clear your cache means a deploy will not impact site
performance. Assuming your deploy system is done right, of course. See https://codeascraft.com/2013/07/01/atomic-deploys-at-etsy/
------------------------------------------------------------------------
[2016-03-09 13:50:57] iquito at gmx dot net
That is possible - the only documentation so far for this feature (that I could find) is in php.ini,
stating:
"Enables or disables checksum validation when script loaded from file cache."
What is validated how is not explained, I thought it would compare the checksum of the binary file
with the original file. If I am misinterpreting this feature, then I think there is at least one
important feature missing for file_cache, something like
opcache.file_cache_validate_timestamps
(and maybe also something similar to opcache.revalidate_freq for file_cache)
Because otherwise you would need to enable opcache.validate_timestamps at all times when using
file_cache, which is counterproductive in PHP-FPM, where you want to check if a file from file_cache
is still up-to-date (because file_cache is the fallback cache) after an "opcache_reset();"
or a restart, but when it is loaded to shared memory it should not be checked anymore.
There could also be something like a "opcache_file_reset();", after which PHP-FPM/PHP-CLI
checks the next loading of a file_cache entry only once, which will benefit CLI - so CLI does not
have to check every cached file all the time. This would be really great, but probably also
difficult to implement, because that information would need to be persisted somewhere for both CLI
and FPM to access it.
As it is now, I think file_cache is not easily usable in PHP-FPM, because no option to only recheck
the cached files exist and many people use "opcache_reset();" with
"opcache.validate_timestamps=0", which is perfect for deploying applications without
downtime and errors (exchanging versions in an instant), but is also not compatible with the new
file_cache.
------------------------------------------------------------------------
[2016-03-09 11:19:23] inefedor at gmail dot com
Looking at the code it seems you misunderstood the purpose of file_cache_consistency_checks
directive. If I'm not mistaken it's only needed for checking if *.bin files are not
damaged (i.e. their checksum is the same).
------------------------------------------------------------------------
[2016-03-09 01:47:43] iquito at gmx dot net
Description:
------------
I did a lot of tests with the new opcache.file_cache possibilities and think that these new features
are great. But as far as I can tell, "opcache.file_cache_consistency_checks=1" has no
effect - there are no checks if files have changed or if the checksum is still the same, at least I
could not make out any noticeable effects.
This is a problem because it is now a bit confusing and hard to clear the file cache - the only sure
way to clear the cache is to delete the cached .bin file. If "opcache.validate_timestamps"
is set to 1, then that also seems to work for the file_cache - an existing file_cache .bin file is
compared with the timestamp of the original .php file.
But in production, "opcache.validate_timestamps" is better set to zero, to avoid file
system requests. Until now, when deploying a new version of an application, I just called
"opcache_reset();" to reload the application, which worked perfectly: in an instant, the
old code is gone and the new code is loaded.
With validate_timestamps set to 0 and with the new file_cache, the file is instead immediately
re-cached from the file system and not checked against the original file - meaning a newly deployed
application is not loaded, the previous state is loaded from the file system. I thought
"opcache.file_cache_consistency_checks" was to specifically address this issue - check if
the file_cache version is still the same as the original file. But this does not seem to work, in
all my tests.
Test script:
---------------
Use the following settings:
opcache.enable=1
opcache.enable_cli=1
opcache.validate_timestamps=0
opcache.file_cache="/srv/php-file-cache"
opcache.file_cache_only=1
opcache.file_cache_consistency_checks=1
Then call a simple script from PHP CLI (opcache enabled), like "<?php echo
'5';" - this file will now be cached. If you change the file to "<?php echo
'7';", this change will never be displayed until you delete the cached file from the
file system.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=71749&edit=1