-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
HttpCache files getting too big #4871
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
Comments
I know this is not a real solution, but the "easy" fix is to use varnish instead of the HttpCache, it'll be faster and does its own housekeeping. You should consider it if it's an option for you. |
That said, a command to clean up old entries would be nice, so it can be ran out of band from the web workers. |
You shouldn't store your dynamic cache on filesystem (except for dev). You need an implementation of the StoreInterface for a real cache engine (APC, Memcache ...) |
The entire module is a ROR re-write... but @GromNaN, if you blindly accept the vary header, wouldn't the virtual storage (once your RAM is exhausted) fill up just as fast as the filesystem? |
Creating a CLI tool to cleanup old entries might be a good idea but it won't do anything interesting for when you are using the validation model. So, we would need to come up with a strategy where we remove the oldest entries, not just the expired ones. Furthermore, this cannot be done in a regular Symfony command as the console application knows nothing about So, the best idea would be to create a new interface ( Anyone willing to investigate this further? |
Take a look in the direction of a caching proxy on nginx and ssi. nginx makes automated cache validation. nginx caching faster than varnish, and places cache on disk. Tests: http://serverfault.com/questions/95679/nginx-varnish-esi-will-that-work |
Generally about caching in highload projects, I realized one thing - it is impossible to validate and generate a cache in the user's request. All these slow things are to be in the background. Better through queue ... Until this architecture - all will be very slow, at least sometimes. |
Same problem here. My workaround here is rm -rf the cache regulary in low traffic times. Varnish would be the next step, then. |
I'd create a PR on it, naming will be the difficult part ... |
In case anyone else is still searching: https://github.com/Toflar/psr6-symfony-http-cache-store |
closing as explained in #6855 |
When using the HttpCache, there are files created in the app/cache/prod/http_cache/md for each url. Each time this url is accessed with a differente cookie, an entry is added (because we do vary on cookie). After some days or weeks this file is getting too big. The expired entries are not removed. I don't know if its best to create a command to remove old items, or to do it after lookup, or after write. Maybe just need to clear the cache every night :)
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/HttpCache/Store.php
The text was updated successfully, but these errors were encountered: