On 24.01.2011, at 09:46, Fabien Potencier wrote: > On 1/23/11 3:04 PM, Benjamin Eberlei wrote: >> If "auto_prime_caches: false" we should add an console option to the still >> to be written "clear cache" command, so that you can call "./app/console >> cache:clear --prime-caches" and it would do the same magic as if >> "container.dumped" was listened too. >> >> This way you can decide for high load environments if you want to prime >> the caches before taking the webserver live again or if you don't care >> because the amount of visitors on your page won't produce a cache slam on >> the first regeneration of the container. > > I have a first working implementation. I have used the word "warmer" instead > of "primer", but the idea is exactly the same. Also, I have not used an event > here, but proper objects. > > Here is a lost of possible cache warmers: > > * Generation of routing matcher and dumper classes > * Generation of aggregated translation files > * Pre-compilation of Twig templates > * Computation of Twig templates paths > * Generation of Doctrine DQL to SQL cache > * Generation of Doctrine proxy classes > * Minification of assets > * ... > > That's a lot and anyone can add more. It can take quite some time to run > (imagine a large application with many Doctrine entities, many Twig > templates, and lots of translation files). > > So, I'm wondering if doing all this on the very first request in the > production environment is really a good idea. > > If we have a closer look, all warmers are optional, except perhaps the > Doctrine proxies generation. So, do we make a difference between mandatory > and optional warmers? If we don't compile the Twig templates for instance, > the cache will be generated on-demand, which is not a big deal. > > So, what about defining three values for the "cache-warmer" option: > > * "false": disable the feature (use the cache:warmup command to warm up the > cache); > * "true": enable and run all warmers on the very first request; > * "min": enable and only run the mandatory warmers on the very first request > (the reset of the cache will be generated on-demand). > > What do you think?
I think for most "serious" deployments, this will be done via ideally a CLI call before the server is added to the cluster. For others I guess it just means that after the deployment they should manually trigger this, but I think in those setups it should probably not take that long anyway. Disk space is also not really a consideration here. So imho we do not need this added complexity. regards, Lukas Kahwe Smith [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
