Req #71881 [NEW]: Mass opcache timestamp recheck instead of reset

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

« previous php.bugs (#200041) next »