Edit report at https://bugs.php.net/bug.php?id=71749&edit=1
ID: 71749
Updated by: cmb@php.net
Reported by: iquito at gmx dot net
Summary: file_cache_consistency_checks has no effect
Status: Open
-Type: Bug
+Type: Documentation Problem
Package: opcache
PHP Version: 7.0.4
Block user comment: N
Private report: N
New Comment:
> The OP has reported a genuine bug in my opinion, but he steered
> the discussion towards consistency checks.
This ticket is explicitely about .file_cache_consistency_checks,
and that documentation should be improved. If you think there is
another bug, and this is still relvant for any of the actively
supported PHP versions[1], please file a new bug report.
> If I'm not mistaken it's only needed for checking if *.bin files
> are not damaged (i.e. their checksum is the same).
Right. This should be documented.
> What's the official method to clear the memory & file cache so
> that changes are detected by opcache, without a race condition of
> manually deleting cache files?
See <https://codeascraft.com/2013/07/01/atomic-deploys-at-etsy/>
and <http://blog.jpauli.tech/2015-03-05-opcache-html/>.
[1] <https://www.php.net/supported-versions.php>
Previous Comments:
------------------------------------------------------------------------
[2019-08-17 01:20:41] rolmos at endertech dot com
Experiencing the same issue. What's the official method to clear the memory & file cache so
that changes are detected by opcache, without a race condition of manually deleting cache files?
------------------------------------------------------------------------
[2017-03-07 07:41:12] persiantools at yahoo dot com
The OP has reported a genuine bug in my opinion, but he steered the discussion towards consistency
checks. I have the exact same problem and expect that opcache_reset will really reset opcache
whether it be in-memory cache or file chaches.
However, It is not the case when you have file caches enabled and set the validate_timestamps to
false. In this scenario, calling opcache_reset or even a web server restart has no effect.
------------------------------------------------------------------------
[2016-03-10 15:28:10] iquito at gmx dot net
My tests only went on for a few minutes, and it was always between 7ms and 10ms slower when the
request hit opcache.validate_timestamps. Why it takes so long - I have no idea. But the numbers are
certainly correct.
Still, the "pull-only-mentality" of opcache.validate_timestamps does not seem sensible to
me - the application should be able to choose when to do that. If I could choose new features for
opcache, the following would seem perfect:
An additional function in PHP like opcache_revalidate_timestamps() which would check all timestamps
within opcache once instead of resetting, and would recache changed files (if they still exist) or
maybe just remove them from opcache if they are changed, both would be possible. Even if 20'000
files need to be checked, doing this once when specifically asked would be more manageable/certainly
faster than PHP doing it in regular intervals. Because PHP is already doing this internally at fixed
intervals when opcache.validate_timestamps is set, such a function should be possible.
This would then be an interesting alterative to opcache_reset(), because most of the opcache will
stay intact, and file_cache could have an equivalent like opcache_revalidate_timestamps_file_cache()
which would do the same for all .bin files. That way all opcache data can be checked with two
functions when needed, and the cache does not need to be reset very often.
------------------------------------------------------------------------
[2016-03-10 05:21:46] rasmus@php.net
10ms in stats on a single request? You either have a seriously slow OS/filesystem combination or you
are measuring something incorrectly. Linux caches inode entries so you never actually touch the disk
since presumably repeated stat'ing every 10-20 seconds is going to have an extremely high cache
hit rate.
On my production servers, a stat takes approximately 0.00034ms which means that in order for that to
add 10ms to a request it would take on the order of 30k stats on a single request. That is a lot of
includes!
------------------------------------------------------------------------
[2016-03-10 04:25:21] iquito at gmx dot net
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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=71749
--
Edit this bug report at https://bugs.php.net/bug.php?id=71749&edit=1