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

From: Date: Wed, 23 Mar 2016 14:37:50 +0000
Subject: Req #71881 [Opn]: Mass opcache timestamp recheck instead of reset
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-200063@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=71881&edit=1

 ID:                 71881
 User updated by:    iquito at gmx dot net
 Reported by:        iquito at gmx dot net
 Summary:            Mass opcache timestamp recheck instead of reset
 Status:             Open
 Type:               Feature/Change Request
 Package:            opcache
 PHP Version:        7.0.4
 Block user comment: N
 Private report:     N

 New Comment:

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


Previous Comments:
------------------------------------------------------------------------
[2016-03-22 17:35:34] 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).



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



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


Thread (2 messages)

« previous php.bugs (#200063) next »