On Wed, Jul 18, 2012 at 11:27 AM, Drake <[email protected]> wrote: > Use warm up requests.
...except that thanks to a recent change, warmup requests don't prevent users from seeing cold starts anymore. In a burst of traffic, GAE will happily route requests to cold instances even if an active instance would have become available 1s later. > Also optimize your code to load faster. I have an app that is HUGE it > loads in about 8s. On an F4. It doesn't fit in an F2. Check that you really > need all your libraries. Check that any of the large blocks of data you have > in code files are in database/memcache. If you need use a Cron to put them > back in memcache every 10 minutes. Believe me, I've gone down this route. 8s is still unacceptable. That's well beyond "user clicks reload because they think site is broken". And you aren't accounting for sick periods when latency goes 2-3X that; how do your users feel about a 24s wait? I have optimized my codebase about as much as I consider reasonable. I don't eager load data, I've turned off any kind of classpath scanning. I've deliberately used GAE-friendly libraries. Hell, I even wrote one myself. When GAE is behaving, my startup time is 20-30s, and could go down to 10-15s if I wanted to quadruple my bill with F4s (I don't). The next step is more or less tantamount to "give up on Java", or at least programming in something that looks like modern Java: * In order to persist POJOs, the classes must be introspected at startup. The alternative is to use only the low-level api; that does not scale to a complicated project. * Nearly every modern Java webapp framework uses annotations to define a sitemap. That means loading and introspecting all those annotated classes before serving the first request. The alternative is to find some early-2000s-era relic based on XML files like Struts1 or WebWork (or this blast from the past: http://mav.sf.net). I'm not even sure it would help; the first thing most of these do is read the XML and load the related classes. * I could probably squeeze a few more seconds out of startup if I dropped Guice and AOP. This would involve rewriting my app more or less from scratch. Aside from my fixed investment, I refuse to go back to programming without tools like these. It's the difference between: @Transact(TxnType.REQUIRED) void doSomeWork() { ...do work } and littering my code with crap like this: Transaction txn = datastore.beginTransaction(); try { ...do work txn.commit(); } finally { if (txn.isActive()) { txn.rollback(); } } Actually, these are not comparable, because the AOP-based example is smart about inheriting a pre-existing transaction context, or starting one if necessary. A truly equivalent second example would include a ton more boilerplate. Without techniques like AOP and DI, Java programming becomes miserable busywork. We picked GAE as a platform because without having to do the work of an ops staff, we can write code and develop features much faster. If I am stuck working at half-speed with crappy tools, then GAE has a negative value proposition - we'd be faster even with the ops load, and paying a fraction of GAE's price to boot. So yeah, I don't expect to see my startup times get much better than what they are today... and if I double my codebase next year, it could get worse. Realistically, I do not expect Google will ever be able to squeeze Java application starts into reasonable timeframes (ie, http://www.useit.com/alertbox/response-times.html). It's just not realistic given the nature of classloading and the security precautions that must be built around it. That kind of JVM engineering is rocket science, and in the last three years it hasn't materialized (although, to Google's credit, incremental progress has been made). This is why I'm thinking about lateral solutions. Honestly I don't really care how long it takes my app to start as long as 1) users never see cold starts and 2) I can expand capacity to meet increased load. From the outside, it really feels like all the pieces have been implemented, they just are misconfigured right now. 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.
