Open GoogleCodeExporter opened 9 years ago
What would the advantage of this be? I think the first request is really where
you want to take the hit, correct? I mean, I can only think of development
speed being an issue, but you develop mostly on the local devserver anyway.
The reason I say this is that it's quite complex to split up the lifecycle this
way--particularly because servlets can depend on each other (how do I know it
has been initialized if it is called from another servlet?)
Original comment by dha...@gmail.com
on 5 Jul 2010 at 7:26
When running on AppEngine, the first request after a JVM shutdown always
includes this Guice startup time. Unfortunately, for low-volume applications,
this first request can happen as often as once per minute. In the case of our
application, the total time to run the Guice module code, load all required
classes from everything in the module, bind the servlets and serve the first
request ends up being around 10s. The end result of this is that the first
person to hit our application every minute basically has to wait 10s for it to
come alive.
I used YourKit and Guice's stopwatch logs to profile my application's startup
and there's not much going on there beyond simple classloading. I hacked up a
filter that lived in front of GuiceFilter (and subclassed GuiceFilter to lazily
initialize the module on the first request rather than using a servlet context
listener). This filter manages to serve the first request in under 3s. This is
probably around the fastest you can get a JVM to come back to life on AppEngine.
I believe that solving this would cut down our application's startup time by
approximately 50% by not initializing every class to serve the first request
(which is likely the homepage and can be served by memcache in most cases).
Original comment by mmast...@gmail.com
on 5 Jul 2010 at 5:05
Original comment by sberlin
on 22 Feb 2011 at 1:44
Original issue reported on code.google.com by
mmast...@gmail.com
on 24 Jun 2010 at 10:10