Hi,
Opening the vote for :
https://wiki.php.net/rfc/streams-is-cacheable
This RFC proposes a generic way for opcode caches to decide if a given URI
is cacheable or not.
Cheers
François
Hi,
Opening the vote for :
https://wiki.php.net/rfc/streams-is-cacheable
This RFC proposes a generic way for opcode caches to decide if a given URI
is cacheable or not.
Doesn't this imply that "path" is the one true cache key? There are some
issues with that which we will have to address at some point. For
example, when running fpm chrooted you need more than the path. We'll
likely need a more APC-like option here to use the device+inode for the
key. It seems like a generic mechanism like you are proposing needs to
take this into account and provide some mechanism that tells the opcode
cache how to determine uniqueness. Perhaps that is simply encoded into
the path parameter, but then maybe it should have a more appropriate name.
-Rasmus
De : Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Doesn't this imply that "path" is the one true cache key? There are some
issues with that which we will have to address at some point. For
example, when running fpm chrooted you need more than the path. We'll
likely need a more APC-like option here to use the device+inode for the
key. It seems like a generic mechanism like you are proposing needs to
take this into account and provide some mechanism that tells the opcode
cache how to determine uniqueness. Perhaps that is simply encoded into
the path parameter, but then maybe it should have a more appropriate
name.
Yes, it implies that the path is the cache key. It implies that the stream
wrapper has a way to build unique and reproducible paths (PHK, for instance,
builds a unique ID from (dev/inode/mtime) when opening a package and builds
its paths from this ID).
My first idea was to add a 'cache_key' element in the stream_stat() result.
This element would be a binary string to use as key. This way, the stream
wrapper can return a path, a dev/inode/mtime concatenation, etc. If we don't
want to modify the stat() result, we can define a 'cache_key' hook in
php_stream_wrapper_ops.
I reverted to a system where path is considered as unique because I thought
my original idea would be considered as too complex. And using the path as
key was enough for phar and phk. But I agree, it is not a good solution for
'file:', which should be cached by dev/inode/mtime.
I put the vote in standby.
Cheers
François
De : Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Doesn't this imply that "path" is the one true cache key? There are some
issues with that which we will have to address at some point. For
example, when running fpm chrooted you need more than the path. We'll
likely need a more APC-like option here to use the device+inode for the
key. It seems like a generic mechanism like you are proposing needs to
take this into account and provide some mechanism that tells the opcode
cache how to determine uniqueness. Perhaps that is simply encoded into
the path parameter, but then maybe it should have a more appropriate
name.Yes, it implies that the path is the cache key. It implies that the stream
wrapper has a way to build unique and reproducible paths (PHK, for
instance,
builds a unique ID from (dev/inode/mtime) when opening a package and
builds
its paths from this ID).My first idea was to add a 'cache_key' element in the stream_stat()
result.
This element would be a binary string to use as key. This way, the stream
wrapper can return a path, a dev/inode/mtime concatenation, etc. If we
don't
want to modify thestat()result, we can define a 'cache_key' hook in
php_stream_wrapper_ops.
I am not a big fan of putting this info on the path. A path must remain a
path or URI, not some random generated string, requiring to be parsed to
get the actual path.
A cache key sounds cleaner, easier to implement and valid.
Hi,
Opening the vote for :
https://wiki.php.net/rfc/streams-is-cacheable
This RFC proposes a generic way for opcode caches to decide if a given URI
is cacheable or not.Doesn't this imply that "path" is the one true cache key? There are some
issues with that which we will have to address at some point. For
example, when running fpm chrooted you need more than the path. We'll
likely need a more APC-like option here to use the device+inode for the
key. It seems like a generic mechanism like you are proposing needs to
take this into account and provide some mechanism that tells the opcode
cache how to determine uniqueness. Perhaps that is simply encoded into
the path parameter, but then maybe it should have a more appropriate name.-Rasmus
Don't we already have this problem with chrooted FPM? I haven't tested it more recently, but last time I tried, opcache would fail to invalidate the cache after updating the file. Worked fine with a non-chroot environment. Not sure if this is related to the issues you mean here...
Hi,
Opening the vote for :
https://wiki.php.net/rfc/streams-is-cacheable
This RFC proposes a generic way for opcode caches to decide if a given URI
is cacheable or not.Doesn't this imply that "path" is the one true cache key? There are some
issues with that which we will have to address at some point. For
example, when running fpm chrooted you need more than the path. We'll
likely need a more APC-like option here to use the device+inode for the
key. It seems like a generic mechanism like you are proposing needs to
take this into account and provide some mechanism that tells the opcode
cache how to determine uniqueness. Perhaps that is simply encoded into
the path parameter, but then maybe it should have a more appropriate name.-Rasmus
Don't we already have this problem with chrooted FPM? I haven't tested it more recently, but last time I tried, opcache would fail to invalidate the cache after updating the file. Worked fine with a non-chroot environment. Not sure if this is related to the issues you mean here...
Yes, like I said, this is an issue we have to address still. It is on
the TODO list and definitely looking for volunteers. I just wanted to
make sure that Francois' RFC didn't introduce something which would make
it harder to eventually fix this by not allowing for a non-path cache key.
-Rasmus
De : Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Don't we already have this problem with chrooted FPM? I haven't tested it
more recently, but last time I tried, opcache would fail to invalidate the cache
after updating the file. Worked fine with a non-chroot environment. Not
sure if this is related to the issues you mean here...Yes, like I said, this is an issue we have to address still. It is on
the TODO list and definitely looking for volunteers. I just wanted to
make sure that Francois' RFC didn't introduce something which would make
it harder to eventually fix this by not allowing for a non-path cache key.
Well, from what I see in accel_make_persistent_key_ex(), the key is the path or a concatenation of the path, the cwd, the include path... Of course, the idea is to avoid the stat() call. But I don't see how we can determine a reliable cache key without a stat().
Maybe opcache shouldn't compute the key by itself. For each file it receives, it would ask the corresponding wrapper for a cache key (and the plain files wrapper would do a stat() and return dev/inode/mtime).
François