Doc #71749 [Com]: file_cache_consistency_checks has no effect

Edit report at https://bugs.php.net/bug.php?id=71749&edit=1

 ID:                 71749
 Comment by:         wirednewsfeed at gmail dot com
 Reported by:        iquito at gmx dot net
 Summary:            file_cache_consistency_checks has no effect
 Status:             Verified
 Type:               Documentation Problem
 Package:            opcache
 PHP Version:        7.0.4
 Block user comment: N
 Private report:     N

 New Comment:

Weird News Feed Blog are sharing latest news about auto, tech, travel, home improvement, health, business, finance, loan, investment etc. More info to visit: (https://weirdnewsfeed.com)github.com


Previous Comments:
------------------------------------------------------------------------
[2021-07-08 11:54:38] [email protected]

> 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>

------------------------------------------------------------------------
[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] [email protected]

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!

------------------------------------------------------------------------


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