Hi, Wanted to bring this topic up once again. Fabien is also concerned about this since he feels the impact on the first request is too high.
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). Cache warming with the CLI: Afaik this is all good? Cache warming and unit tests: It should also be noted that right now "true" and "min" have no effect for CLI scripts scripts. This makes sense since after all on the CLI you can just call the cache warming CLI command. However it sorts of sucks for unit testing. For this I created a new option "force" [1] which could be used in the test configuration, but that also seems to not be ideal, since this would cause cache warming when one is just calling any CLI command on the test console. So maybe I should instead do the cache warming CLI command inside my phpunit bootstrap (I guess via exec(), since at this stage there isn't really a container yet, though of course an instance could be created). Cache warming without CLI: Now for the performance issue on the first request. Obviously this can be controlled a bit by what is enabled etc, but this then also reduces the usefulness. In theory one could randomly cache warm something else in subsequent requests until finally all cache warmers have been executed. All the while not yet cache warmed things would be generated on demand. This would mean no single request has to cache warm everything and after the first X request things should be cache warmed completely as each request randomly finds a new item on the check list to complete. Then again this would require all sorts of magic to prevent cache slams etc. Its my understanding that there is nothing that really needs to happen via cache warming if things are configured properly (aka proxies being generated on the fly etc), but without it again performance might suffer and also one might not realize that broken permissions prevent something from being cached. That being said what is the target audience for this feature?: 1) people that do not want to bother themselves to call the CLI command 2) people that do not have access to the CLI command I do not think we really need to deal with 1), this group should just be steered towards having everything generated on the fly. For 2) there might still be people who do care about performance, yet still are on a shared host without CLI access (phpBB users). Now for these they will need some sort of admin panel anyway to do installation of Bundle's etc and imho that could also be the place to put any sort of intelligence about cache warming via a web SAPI. ----- So in other words I am not sure what we really can/should improve/change? regards, Lukas Kahwe Smith [email protected] [1] https://github.com/fabpot/symfony/pull/618 -- 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
