Req #71881 [NEW]: Mass opcache timestamp recheck instead of reset
| From: | iquito at gmx dot net | Date: | Tue, 22 Mar 2016 17:35:38 +0000 |
| Subject: | Req #71881 [NEW]: Mass opcache timestamp recheck instead of reset | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-200041@lists.php.net to get a copy of this message | ||
From: iquito at gmx dot net
Operating system:
PHP version: 7.0.4
Package: opcache
Bug Type: Feature/Change Request
Bug description:Mass opcache timestamp recheck instead of reset
Description:
------------
For PHP opcache to notice changed files / updated applications there
currently are only two options:
- Set opcache.validate_timestamps to 1 (which is usually
overkill/unnecessary overhead in production environment, where 99% of
files hardly ever change)
- opcache_reset() , which gets rid of all contents of the current cache
I suggest to offer a third possibility, which is inbetween these two
options: To validate all timestamps on demand through a PHP function
which could be named opcache_revalidate_timestamps() or
opcache_invalidate_all() (or something similar). It would
invalidate/recache changed files and remove deleted files.
This functionality is probably already contained in PHP because
opcache.validate_timestamps works like this, and opcache_invalidate() is
also very similar to my proposal, with the exception that you have to
name every file individually instead of PHP just checking all files in
opcache.
This would greatly increase the possibilities to deploy applications and
manage servers - many usages of opcache_reset() could be replaced by
opcache_revalidate_timestamps() and opcache would need fewer warmups in
many environments. Only resetting the opcache every 30 days instead of
maybe 5x a day would be great for most applications.
The same functionality could also be implemented for the new file cache
- something like opcache_filecache_revalidate_timestamps() (or maybe
something more succinct). This would make it possible to set
opcache.validate_timestamps to 0 even for combined opcache/file cache
usages (and maybe other scenarios I did not envision yet).
--
Edit bug report at https://bugs.php.net/bug.php?id=71881&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=71881&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=71881&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=71881&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=71881&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=71881&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=71881&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=71881&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=71881&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=71881&r=support
Expected behavior: https://bugs.php.net/fix.php?id=71881&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=71881&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=71881&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=71881&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=71881&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=71881&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=71881&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=71881&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=71881&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=71881&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=71881&r=mysqlcfg