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.
