Brandon, This is very helpful (maybe a little funny too, but that might depend on who the reader is :)). I have questions Re: *"**If you don’t have concurrency that means you need to handle them in serial, unless you have more than one instance"*: I am one of those cheap people who insist on keeping $MII to 1, even though, during the day, my num-active-instances hovers around 10, and spikes to ~25 occasionally. I see this as "I'm only paying for one instance, but I'm getting 25 for free". However, I understand (and it is also apparent from your calculations below) that I'm paying somehow, because of increased latencies, and eventual timeouts. I'm counting on the fact though, that my app startup time is around 200ms (not 15 seconds as in your example), and I have set $MPL to 50ms. I expect GAE to spawn multiple new instances indefinitely to service spikes in my load. Each new instance will take 200ms to spawn, and assuming a 15 second timeout for my client, I expect I can handle 75 concurrent requests before my client starts to see timeout errors. Do you agree? I'm just looking for some confirmation for my calculations. If course, since I'm lazy too (and maybe stubborn as well), I have stayed married to python2.5, and this means 75 concurrent requests will get served by 75 GAE front-end instances. Do you think GAE will spawn 75 instances, given my $MII=1, and $MPL=50ms, in response to a 75 request spike in my load?
Thanks in advance. On Mon, Dec 5, 2011 at 7:10 PM, Brandon Wirtz <drak...@digerat.com> wrote: > I’m too lazy to build a tool to calculate this for you. **** > > ** ** > > The Formula for non-concurrent tasks is pretty simple. **** > > ** ** > > How many simultaneous requests do you need to handle? (Hint Chrome will > request 8 assets at a time) If you don’t know I’m telling you it is 10.*** > * > > ** ** > > Great. So you need to handle 10 requests. If you don’t have concurrency > that means you need to handle them in serial, unless you have more than one > instance.**** > > ** ** > > How Many instances do you have? 1 Because if you are asking about this > topic I assume you care enough to set 1 for always on, but you set idle to > 1 because you are cheap.**** > > ** ** > > How Long Does your App take to spin up? 15 seconds. Mine doesn’t take this > long, but yours does because I needed to pick a number that accounts for > all you people who get the errors when your app spins up.**** > > ** ** > > How long does the average request take to fill? 2 seconds. I pulled this > out of my ass, you should be a good person and shoot for 1 second but > things happen, yours take 2.**** > > ** ** > > OK. Soooo we now have all the numbers we need**** > > ** ** > > ** ** > > $CI = Current Instances**** > > $MII = Max Idle Instances**** > > $MPL = Max Pending Latency**** > > $ART = Avertage Request time**** > > $SR = Simultaneous Requests**** > > $**** > > ** ** > > $SR[8] / $CI[1] * $ART[2] = Seconds to fill requests. In this case 16 If > your app was idle before the first request came in chances are that the > user timed out the 8th request as it will generally only wait 15. You > Errored.**** > > ** ** > > So we kick on Max pending Latency of 200Ms Why that number it sounded nice > a lot of you pick this number.**** > > $SR[8] / $CI[1] * $ART[2] -> 16 Seconds of stuff to do, we need 8 > instances to try and get it all done because with 200 ms for a pending, no > task can be pending it takes too long…**** > > ** ** > > Spin up $MII [1] Instances**** > > We now have 1 instance for the first 5 seconds and 2 after it gets spun > up, so**** > > Instance 1 fills Request 1,2,3**** > > Instance 2 fills request 4**** > > 5,6,7,8 are still pending, we should spin up $MII[more instances because > everyone is busy and more than 200ms out**** > > Instance 3 fills 6**** > > Instance 1 fills 7**** > > Instance 2 Fills 8**** > > ** ** > > But the browser timed out Request 4 because it was 15 seconds before the > instance started to spin up, it took 15 seconds to spin up instance 3 so > that request failed, as did request 8.**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > 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. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. 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.
