Req #73887 [Com]: Improve realpath cache eviction strategy
| From: | spam2 at rhsoft dot net | Date: | Wed, 26 Jul 2017 10:17:58 +0000 |
| Subject: | Req #73887 [Com]: Improve realpath cache eviction strategy | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-210346@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=73887&edit=1
ID: 73887
Comment by: spam2 at rhsoft dot net
Reported by: maggus dot staab at gmail dot com
Summary: Improve realpath cache eviction strategy
Status: Open
Type: Feature/Change Request
Package: Performance problem
PHP Version: any
Block user comment: N
Private report: N
New Comment:
first it would be much more important to have the cache shared between workers and so fix the
split-brain and overhead of maintaining a cache for every process with a very bad hitrate on mahines
with hundrets of workers
see https://bugs.php.net/bug.php?id=73888 -
"We recently changed the default realpath cache" is a big mistake as long as verey single
worker has it's own cache with that size and clearstatcache() after change a file don't
work at all with the current design
Previous Comments:
------------------------------------------------------------------------
[2017-01-07 13:45:40] maggus dot staab at gmail dot com
Description:
------------
We recently changed the default realpath cache size as we realized that the default size is too
small, see https://github.com/php/php-src/pull/2271.
After a closer look into the realpath cache impl krakjoe and bwoebi mentioned, that cache eviction
of this cache is very suboptiomal. Cache items are only evicted after a find. Entries never get
evicted when no longer used.
Php is forced todo some expensive file-io operations when the realpath cache cannot deliver the
information from memory. This is especially expensive for long running php scripts, like cli based
processes/webservers/...
A first improvement would be some kind garbage collection, which isnt bound to a previous find.
2nd the cache could benefit from some kind of LRU cache.
3rd krakjoe mentioned that it might be sometimes usefull to share the cache information in shm.
Related discussion: http://chat.stackoverflow.com/transcript/message/34952738#34952738
Starting 5:32 PM
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=73887&edit=1