On 1/23/11 3:47 PM, Benjamin Eberlei wrote:
Hello Fabien,
i am working on the Doctrine 2.0.1 release today, so if you want to take
it feel free :-) Johannes had one objection, that the listeners would still
be injected for all requests, so he proposed to make this a compiler pass
instead and re-use the compiler pass in the console command if its to be
done manually. I am not sure what the better approach is here, i don't
grasp the internals of the event dispatcher enough.
Doing this in a compiler pass is doable and indeed better for
performance, but it is the wrong layer. Cache priming has nothing to do
with building the container.
Fabien
greetings,
Benjamin
On Sun, 23 Jan 2011 15:32:32 +0100, Fabien Potencier
<[email protected]> wrote:
Excellent idea! but I would not named it container.dumped. What about
"core.prime_cache"?
Do you want to work on the implementation? If not, I have some time this
afternoon.
Fabien
--
Fabien Potencier
Sensio CEO - symfony lead developer
sensiolabs.com | symfony-project.org | fabien.potencier.org
Tél: +33 1 40 99 80 80
On 1/23/11 3:04 PM, Benjamin Eberlei wrote:
Hello everyone,
let me run an idea through you all. There is a lot of complaints and
confusion about Doctrine 2 Proxies having to be generated explicitly in
the
Production environment. Forgetting this will kill your application
compared
to the dev env where auto generation of proxies is done on a per
request
basis. I agree that this is annoying and hence put fort the idea of a
new
event "container.dumped". This event will be fired inside Kernel only
when
a new container was dumped.
A new listener "PrimeCacheListener" will be put on this event if any
only
if a parameter "auto_prime_caches: true" is enabled in the "web"
extension.
This listener collects a bunch of services tagged "cacheprimer". A
cache
primer can then go and "prime its own caches", this means a
DoctrineProxyCachePrimer will automatically generate the proxies on the
first and only first request that generates a new production container.
The same could go for twig template rendering, Doctrine DQL to SQL
cache
generation or any other cache priming mechanisms such as asset
minification
and such stuff.
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.
Any comments?
greetings,
Benjamin
--
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
