php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #71881 Mass opcache timestamp recheck instead of reset
Submitted: 2016-03-22 17:35 UTC Modified: 2016-03-23 14:37 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (50.0%)
From: iquito at gmx dot net Assigned:
Status: Open Package: opcache
PHP Version: 7.0.4 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: iquito at gmx dot net
New email:
PHP Version: OS:

 

 [2016-03-22 17:35 UTC] iquito at gmx dot net 
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).

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-03-23 14:37 UTC] iquito at gmx dot net 
My current solution to emulate this feature is the following (a slight variation to my original proposal):

- Get all used scripts from opcache_get_status() and write them to a file
- Do a opcache_reset()
- Call opcache_compile_file() in another request for all scripts in the previously written file

Doing this in PHP yourself just has a few drawbacks:

1. You cannot start calling opcache_compile_file() immediately after opcache_reset() - probably because of race conditions/opcache not being ready yet. Not knowing when the opcache will be ready makes it hard to be as fast as possible (because there is no official function/way to check if opcache is ready).
2. Doing this manually is generally slower than if PHP does it itself in an optimized manner.
3. For extremely busy sites PHP could start & warmup a new cache before deleting the old cache. This would make this solution viable even in demanding applications with the only drawback of higher temporary memory usage. In my solution something like this is not possible - there are always a few seconds where opcache is not ready/empty/being initialized.

Internally, there are many possibilities to enhance a feature like this further:

- Do not recompile scripts which have not changed, instead just copy them or store them temporarily until new opcache is ready
- Instead of only comparing timestamps, something like an MD5 hash could be used additionally, because in many applications timestamps are updated (because a file is recreated or because of a git reset) but there is no change. This may be more of a nice-to-have for even better performance
- Use the file cache somehow to improve performance
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Oct 26 12:00:01 2025 UTC