Interesting; thanks for the clarification. Even though there is no classpath scanning, it does seem like you are loading AND introspecting the majority of your classes upon initialization. Regardless, clearly it is confounding that it takes so long.
I don't have access to all the information you requested from my current location, but I will try to get it later. I can safely say that my project is indeed much smaller than yours. I do know that I have 16 Entity classes registered with Objectify (not including any @Serialize), and 24 jars in WEB-INF/lib. As I said, no other frameworks are used. In _ah_warmup, I load the DAO classes, which register Entity objects via static initializer. To be fair, I am using a Servlet for _ah_warmup, and so probably defer the cost of JSP initialization (which I believe you mentioned somewhere that you do not use, anyway). From a brief look at the logs, it seems as though the first JSP request after a warmup takes about 1 second longer than normal. This would indicate a total initialization time of around 4-5 seconds. I should probably point _ah_warmup at a JSP page to get a more accurate cold start average. On Monday, June 18, 2012 1:34:17 PM UTC-4, Jeff Schnitzer 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 > -- 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/-/z1twpyvbTIgJ. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
