On Sun, Jun 17, 2012 at 8:44 PM, Takashi Matsuo <[email protected]> wrote: > > I'm sorry if I miss something, but I don't think these kinds of > introspection are fundamentally necessary because the class definition > doesn't change during a single version, so you can introduce some > caching mechanism. > > Also, I think there are some workaround like setting appropriate > number of Min Idle Instances, or using backends instances. Didn't they > help you here at all?
Hi Takashi. The problem is that I can't get a single instance started. Min idle instances won't help me if my app can't start before the 60s cutoff deadline. Caching doesn't help because I can't get an instance off the ground in the first place. If my understanding is correct - that network classloading is the major lag - then here is the rough summary of my problem: * My "sitemap" (ie the mapping of URIs to code) is determined by @Path annotations on 80+ classes. This is the JAX-RS way. The alternative is the history of defining all URIs in xml files like web.xml or struts.xml - an approach that was wholly abandoned by the Java community at least 5 years ago. * In order to serve even a single request, all 80+ of those classes need to be loaded. The actual # is quite a bit larger because those classes depend on other classes, and presumably there's some sort of transitive classloading process - but this exceeds my knowledge of java classloading. * To perform the very first datastore operation, there's quite a lot of classloading required to get the persistence system off the ground. This isn't really optional. The first datastore request could be "load key Vehicle(123)" and the persistence mechanism needs to be able to understand that this is a polymorphic Airplane. So any kind of ORM system (like Objectify) needs to classload and introspect every possible class *before* any requests hit the datastore. * Consequentially, there is a minimum number of classes that my app must load at startup time. There is no way to lazy-load them because they are all necessary to 1) establish the JAX-RS sitemap and 2) establish the persistence context. > 'Making class loading faster' would be definitely a constructive > feature request. It's worth filing an issue and seeing how it > interests people. Here: http://code.google.com/p/googleappengine/issues/detail?id=7706 Note that we - the user community - really have no idea if classloading is the issue. Is it? We're guessing based on observed behavior; we just know that it takes an oddly long time for our app instances to start. It would be helpful if someone from Google described the underlying architecture so that the community could both provide constructive feedback and figure out workarounds. Also, while this happens to be hitting me directly, I urge you guys to take this as seriously as possible - I'm about as GAE-savvy as anyone gets without a @google.com email address, and I can't think of a workaround for this problem. I'm generally very sympathetic to making my app work "the GAE way" instead of using traditional JavaEE design patterns, but "remove features" is not really an option. My codebase is going to grow significantly before the end of the year. > On Mon, Jun 18, 2012 at 9:57 AM, Thomas Wiradikusuma > <[email protected]> wrote: >> Just my 2 cents, >> >> If indeed our app needs to be single-JARred and obfuscaticated (at least >> removing unused code), IMO that feature should be baked in the tool. >> Probably triggered with extra flag. > > I think this is also a good feedback especially if creating the single > JAR contributes the performance. I'd appreciate it if you could file > an issue. Someone in Google - possibly you - knows if this will be the case without us having to guess. Can you describe how the GAE classloader works? Does it make a separate network request per classfile? Please don't make us guess at what will improve startup performance, give us some guidance. Thanks, Jeff -- 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.
