This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Cache] Cannot warm or clear APCu cache from CLI with apc.enable_cli
set to false
#53962
Comments
(I think I've got that code example right....) |
Hmm I had assumed that this I've updated the code example to include a timestamp in the value so it's clearer when there's a hit vs a miss. |
apc.enable_cli
set to falseapc.enable_cli
set to false
More on this - looks like even if I enable So... maybe that's just explicitly not supported by APCu? |
APCu cache is not the kind of cache you may be used to everywhere else. This is a shared cache. It works for PHP-FPM (child processes accessing cache from parent) and mod_php. While it works for CLI too it does not make any sense to use it, since each CLI process dies at the end of execution and thus loses all cached information. CLI processes do not have access to cache created from web requests (php-fpm, mod_php), this is why there are community made "monitoring scripts" for APCu. I used such a script too: https://github.com/nvthaovn/APCu-Gui-Admin I could clear the cache from this admin panel or by restarting the php-fpm service. The latter was just a consequence if we had to restart the service for other reasons though. More on APCu and shared cache: https://stackoverflow.com/questions/34533695/is-the-new-apcu-apc-user-cache-shared-between-processes In conclusion if you want to warmup cache from the CLI for the web too, I would suggest you choose Redis or perhaps memcached. If you insist on using APCu and the CLI, there are possible "hacky" solutions I would personally come up with. You can create a special route which is secured and visited from the CLI, this will actually be a web request (but triggered from the CLI) which warms up your cache. Feel free to correct me, if I'm wrong, but this is my experience with APCu and CLI. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Symfony version(s) affected
>= 3.4
Description
If
apc.enable_cli
is not set to true, theChainAdapter
will skip theApcuAdapter
even ifApcuAdapter::isSupported()
returnstrue
.This change was introduced in #36555
This means that CLI can't be used to warm APCu cache even when that is actually supported.
How to reproduce
I think the order you need to run this is:
apc.enable_cli
set to true)apc.enable_cli
set to false (or maybe not set at all?)apc.enable_cli
set to true) again.The first run will set the cache in APCu.
The second run will clear the cache - but since it's skipping APCu it only clears the (already empty) filesystem cache. It then sets a value into the filesystem cache.
The third run will get a cache hit from APCu - it completely ignores the fact that the CLI run was meant to clear it and set a new value.
This should get you into a state where the CLI output is always different from the non-CLI output (at least until the APCu cache times out, at which point you might get lucky and they'll sync up)
Possible Solution
Ideally, that
continue
inChainAdapter
's constructor would just be outright removed.If we want to be really careful, then if
apc.enable_cli
is not set totrue
the chain adapter could skip it anywhere that reads the adapter's cache, but still use it to set cache so it can warm that cache up and clear it.I don't fully understand how the internals of this component work so I can't speak to the feasibility of that.
Additional Context
Note that in #25080 the suggestion to check
apc.enable_cli
to determine whether APCu was rejected specifically because it would prevent this use case - so obviously this at least used to be an intended use case.The text was updated successfully, but these errors were encountered: