Hi Igor, I understand your frustation here. We are also frustrated. It's still unacceptable to serve user request with cold instances (in java) and have such high latencies. We see idle dynamic instances that do not serve traffic and new instances being spun up. I don't want to repeat describing what the issues are, you know them. why does it take more than half a year to solve this issue? Issue 7865<http://code.google.com/p/googleappengine/issues/detail?id=7865>: User-facing requests should never be locked to cold instance starts It's critical for low traffic apps.
I do not want to be rude but It might be time to stop sticking to your position and listen to your customers unsatisfaction. We've been complaining about this for years now. May be it's time to rethink what the scheduler should be, from scratch... Hoping to be heard, Gael Le vendredi 1 février 2013 00:14:49 UTC+1, Igor Kharin a écrit : > > OK you won. This was discussed back and forth countless times ever since > new performance settings introduced. Every. Month. I've tried. The team > also did. I guess it is how this work as you can't keep explaining the same > things to everyone. > > >> A high minimum allows you to prime the application for rapid spikes in >> request load. App Engine keeps that number of instances in reserve at all >> times, so an instance is always available to serve an incoming request, but >> you pay for those instances. This functionality replaces the deprecated >> "Always On" feature, which ensured that a fixed number of instances were >> always available for your application. Once you've set the minimum number >> of idle instances, you can see these instances marked as "Resident" in the >> Instances tab of the Admin Console. > > > > Note: If you set a minimum number of idle instances, the pending latency >> slider will have less effect on your application's performance. Because App >> Engine keeps idle instances in reserve, it is unlikely that requests will >> enter the pending queue except in exceptionally high load spikes. You will >> need to test your application and expected traffic volume to determine the >> ideal number of instances to keep in reserve. > > ... > > The second slider sets the *maximum* period of time (at most 15 seconds) >> that the scheduler will wait before resolving to create a new instance for >> the request. >> >> - A high maximum means users may wait longer for their requests to be >> served (if there are pending requests and no idle instances to serve >> them), >> but your application will cost less to run. >> >> Your arguments are absolutely valid, though. Back then we all thought > resident instances are just more flexible version of what "Always On" was, > but they are not (and that's why engineers were forced to explain it here). > > Yes, an instance *might *be able to serve up to 10 concurrent requests, > but it's much more complicated. Johan Euphrosine explained it in all the > details: > > http://stackoverflow.com/questions/11525717/when-does-the-app-engine-scheduler-use-a-new-thread-vs-a-new-instance/11882719#11882719 > > > On Fri, Feb 1, 2013 at 5:04 AM, Mike Brown <virtua...@gmail.com<javascript:> > > wrote: > >> >> I'm sorry but this is *not* what the documentation says and certainly >> not expected. >> It says: >> >> - https://developers.google.com/appengine/docs/adminconsole/instances >> "You can specify a minimum number of idle >> instances<https://developers.google.com/appengine/docs/adminconsole/performancesettings#minimum>. >> >> Setting an appropriate number of idle instances for your application based >> on request volume allows your application to serve *every request with >> little latency*, unless you are experiencing abnormally high request >> volume." >> >> The key word here being *every.* >> >> The way the scheduler is currently working does not, in any situation, >> allow me to handle *every* request with little latency. >> As I mentioned I started up 5 resident and *still* got 2-3 dynamics >> while the residents sat idle. >> >> It is completely counter intuitive that I would be paying an hourly rate >> for a resident instance only for it to sit idle while dynamic instances are >> spun up to handle requests. What makes complete sense is dynamics are >> started only if the load is beyond what the residents can handle. >> >> What would make for a real scheduler would be for it to be predictive in >> starting up dynamics before they are needed and then not load balancing to >> them until they are completely spun up and ready. Having a calls block on >> instances starting up is just lame. >> >> Also, I read somewhere (not sure if it was official documentation) that >> an instance should be able to handle up to 10 concurrent requests. I am not >> getting anywhere near that. >> >> >> -- >> 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-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.
