I'm not that experienced with GAE, but I'm wondering whether it really is that simple. If an instance of my app takes 10s to start up, and my app can, at peak, receive X requests in a 10s period, then wouldn't I require close to X idle instances running all the time to satisfy your criteria. And wouldn't that be prohibitively expensive for most apps?
If my understanding is correct, then I think a simple on/off option (which has been suggested) would not be a good solution for most developers. I certainly want them to figure out how to reduce response latencies and instance startup times, but I would need to be in control of the balance between response time and cost. As to your point about Heroku/Azure, do you know how they resolved the problem? Did they manage to significantly reduce startup times or have they come up with some other scheme? One final point - I'm baffled at Google's decision to support Go on GAE. When I looked at Go and wondered about design decisions that seemed odd, the answer I always got was that it was designed to reduce build times for enormous systems. How does that primary design criteria make it suitable for GAE? If they had instead added a runtime for something like LLVM then people like myself (and the vast number of other devs who know C/C++/OC) could take advantage of the near-instantaneous startup times that you are talking about, with our existing skills and libraries. Tom On Thursday, May 23, 2013 2:07:18 PM UTC-4, Ryan Chazen wrote: > > And it's possible to not use app engine at all, and then not have to worry > about how fast your app starts. As a bonus, it's far cheaper as well! > "Possible" is never a useful word to throw around here - it's possible to > rewrite your java webapp in Go, it's possible to convince people they don't > even need a webapp and just use pen and paper. > > The point is, GAE/J pointing user requests to servers that have not > finished loading is broken, and Google needs to fix it if they want to > compete with Heroku/Azure/etc who all seem to have this issue sorted out. > This isn't some kind of technical impossibility here - every other hosting > provider of this type manages to solve this issue. And GAE is the most > expensive of the lot in terms of compute resources. GAE should be offering > the best solution, not a "jump through hoops and pray it works until the > next GAE release where everything crawls at half speed for a day" solution. > > > > On Wed, May 22, 2013 at 11:53 AM, Bediako George < > bediako...@lucidtechnics.com <javascript:>> wrote: > >> So our Airlift application framework starts up pretty much immediately on >> App Engine for Java. >> >> It runs on the Java runtime, but developers write request handlers in >> JavaScript via Rhino. Even though it is production ready (we do have >> several customers using it already) it is not ready for public consumption >> (we are looking to release it at the end the summer). >> >> I am not mentioning this as an alternative to what you are doing. >> Instead, I want to make the point that it is possible to create a >> framework in Java that plays well with App Engine. >> >> https://github.com/LucidTechnics/Airlift >> >> Bediako >> >> On Friday, May 17, 2013 2:20:53 AM UTC-4, Marcel Overdijk wrote: >>> >>> This is an interesting question indeed. >>> >>> I don't believe startup times for Java will become better on GAE; it's >>> also very typical for in Java land that startup times take > 30s for medium >>> to large apps or depending on the frameworks chosen. >>> This is no problem when you up front spin up the number of required >>> instances like on a VPS or CloudFoundry PaaS. >>> One of the great things about GAE is the programming API and the >>> autoscaling part, but this autoscaling (and thus spinning up and killing >>> instances) bites back unfortunately. >>> >>> Couldn't Google prohibit cold requests being served to users? In many >>> cases it would better to have latency when a requested is routed to a warm >>> instance. >>> I think this would solve many problems. What do you think? >>> >>> To bad Google is not participating in these discussions. >>> >>> But with great technologies and frameworks being delivered by Google >>> (like Angular JS) Google cannot be taken seriously when they say just go >>> back 10 years and use servlets, static factories, hard coded configs etc. >>> This is a real development nightmare. >>> >>> ^M >>> >>> >>> On Friday, May 17, 2013 1:21:22 AM UTC+2, jeffrey_t_b wrote: >>>> >>>> Jeff, I believe that you had asked on this list, a while ago: In what >>>> circumstance is it _ever_ good for user requests to see cold starts? >>>> >>>> Did you ever get an answer to that? That is the part that puzzles me >>>> still. Is it just too hard? Maybe they don't have a _scalable_ algorithm >>>> for directing requests to already-existing instances? >>>> >>>> Anyway, with all of the focus on the Compute Engine side, I wonder if >>>> improvements to App Engine are going to deprioritized. >>>> >>>> >>>> >>>> On Wednesday, May 15, 2013 4:52:51 PM UTC-7, Jeff Schnitzer wrote: >>>>> >>>>> I attended the "Autoscaling Java" session at Google I/O. In summary, >>>>> the advice is: >>>>> >>>>> * Don't use dependency injection. >>>>> * Don't use AOP. >>>>> * Hardcode configuration values as much as possible. >>>>> >>>>> In other words, go back to Java circa 2002. There was no discussion of >>>>> changing routing so that user requests don't see cold starts. I asked >>>>> about >>>>> this in person - apparently they're still "talking about it" and nothing >>>>> has been done about it. >>>>> >>>>> I am sad. >>>>> >>>>> Jeff >>>>> >>>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Google App Engine" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/google-appengine/Nz4Yt8V6PB0/unsubscribe?hl=en >> . >> To unsubscribe from this group and all its topics, send an email to >> google-appengi...@googlegroups.com <javascript:>. >> To post to this group, send email to >> google-a...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/google-appengine?hl=en >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
