My Project: # of classes in WEB-INF/classes: 1074 (jarred into a single jar for faster deployment) Size of WEB-INF/classes: 9.0M (jars down to 3.3M) # of jars in WEB-INF/lib: 87 Size of WEB-INF/lib: 90M
Frameworks initialized: JDO PMF (3-6secs) JAXB single context (4-10 secs) Guice (2-4 secs) - just dipping my toes back in the water with guice on gae, only one experimental @Inject. Abandoned Guice previously due to initialization time concerns. JDO classes ~ 14 entity types JAXB beans ~ 146 Guice - single @Inject Fastest observed startup time: 11s Typical startup time: 20s Slowest startup time: 25s+ A few weeks ago I must have been moved to a new data center. Prior to that I was seeing between 2-3 times worse performance, for months. Both for instance initialization (which was 20-50+ secs), and general request latencies. This application is relatively small compared to some of the J2EE applications I've worked on in the past. /Tom On Jun 18, 1:34 pm, Jeff Schnitzer <[email protected]> wrote: > This is incorrect. Guice does not perform classpath scanning, and > while classpath scanning is nice for making JAX-RS @Path annotations > work, it is optional and I have disabled it. > > The way it works is that you explicitly register the classes that have > annotations. So each of them individually must be classloaded at > startup. Despite the lack of classpath scanning, this process is > still taking an excessive amount of time. Using Objectify is similar; > all entity classes must be explicitly registered and introspected > before datastore operations begin. > > So... this problem goes way beyond classpath scanning. The problem is > getting classes loaded up front, and this problem doesn't expose > itself until your application reaches a significant level of > complexity. By this standard, Objectify is a "heavyweight" framework > - the only way around loading entity classes up-front is to use the > low-level API. > > I am impressed by your 3.5 second startup time. Does that include a > datastore hit (ie Objectify registration)? How big is your project? > Would you complete this straw poll, filling in your answers? Everyone > else reading with Java instances, would you do the same? > > My project: > > # of classes in WEB-INF/classes: 619 > (cd war/WEB-INF/classes; ls -R | grep class | wc -l) > > Size of WEB-INF/classes: 3.3M > (cd war/WEB-INF/classes; du -sh .) > > # of jars in WEB-INF/lib: 54 > > Size of WEB-INF/lib: 42M > (25M of this is GAE SDK) > > # of classes registered with Objectify: 36 (plus maybe half that again > in @Embed and @Serialize classes) > > # of classes registered with other means (any explicit classloading, > ie JAX-RS): 100+ > > Fastest observed startup time: 20s > Typical startup time: 50s > Slowest startup time: deadlined 60s+ > > I readily acknowledge that I have a fairly large number of jar > dependencies. However, I'm not scanning them. They're also (almost) > all essential for certain features; I do a lot of integration with > third-party APIs. At best I can get rid of one or two by rewriting a > few sections of code. > > Also... this project isn't really that big as enterprise projects go. > I've worked with much, much larger codebases in the past. I shudder > to think what that would do to appengine :-( > > Jeff > > On Mon, Jun 18, 2012 at 7:26 AM, Michael Hermus > > > > > > > > <[email protected]> wrote: > > Jeff, > > > If by "going back to Java programming circa 2002", you mean not using > > annotation processing that requires full classpath scanning, I think that is > > in fact the only solution right now. Based on my limited research, I think > > you really need to stay away from that in order to avoid cold start time > > problems with GAE Java. In fact, the 'Best Practices' section of the > > Objectify wiki is one of the first places I saw this. > > > Although you say have no classpath scanning, the JAX-RS @Path processing is > > exactly that. In addition, I am almost sure that Guice is scanning the > > entire classpath for @Inject annotations as well. I wholeheartedly agree it > > stinks that you have to avoid leveraging awesome frameworks like those (and > > hence having better, more maintainable code) in order to have a properly > > functioning GAE Java application. I would gladly star any feature request > > you make in this direction. However, for now I am staying away. > > > As a reference, I use only Objectify and a few other standard java > > libraries, but no heavyweight frameworks, and my _ah_warmup requests have > > been recently averaging about 3.5 seconds. > > > -Mike > > > On Saturday, June 16, 2012 5:56:33 PM UTC-4, Jeff Schnitzer wrote: > > >> We're having a big problem with instance startup time. It varies > >> between 20s and 60+ seconds, and lately it's tending towards the high > >> end. We're starting to experience downtime because instances get > >> deadlined before they go active. > > >> This app is well optimized for GAE. There's no classpath scanning and > >> it doesn't try to eagerly load data. On a good day it starts in > >> 20s... so at this point there's not really much I can do. > > >> I have a cron task that performs a db cleanup once a minute, and since > >> crons can run over 60s I can eventually get one instance started, > >> which is enough to serve traffic at the moment. But at this point I > >> can no longer deploy code over old versions because the appserver > >> restart will fail. > > >> Please help. > > >> Jeff > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To view this discussion on the web visit > >https://groups.google.com/d/msg/google-appengine/-/YHU-mGVlPAsJ. > > > 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/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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/google-appengine?hl=en.
