On Fri, Oct 23, 2015 at 6:43 AM, Ryan (Cloud Platform Support) < [email protected]> wrote:
> Anastasios hit the nail square on the head. Idle instances are instance > that are doing nothing. When a request comes in it will start a 4th. With > your setup it will be more aggressive in shutting down the spare instances > that's all. They are meant to have instances always ready to take requests. > Depending on the language you are using it is more or less important to > have these. Python is the fastest to boot, so you don't need as many, Java > is the longest to boot so you need more idle. > When I last measured this for myself (a while ago) I noticed that Go was fastest (for a "hello world" app responding to a request starting from a state with zero instances running). Considering that Go is the only GAE runtime where applications are compiled to native-code binaries (no JVM or Python or PHP interpreter needs to spin up), this did not surprise me. However, you're better off doing your own measurements, since things may change. > If Anastasios assumptions are correct and there are no end user > interactions you can leave it at 0 and just take a slight hit when you send > your first request. > > It looks like you want to only ever have 3 instances. You should use > Manual scaling with instances set to 3. > If you have no need for instant response you can use basic > with max_instances set to 3, this will scale down the number when they are > not needed but cap at 3. > That's what I've been doing, personally, for modules that don't respond to users' requests, but rather only do "background processing" (cron and/or queued tasks) -- I forego autoscaling for those modules, in favor of basic or manual scaling, since for those modules I can usually predict the load reasonably well in advance and don't need to provision for sudden surges as I have to for modules that respond to users' requests (and besides having more predictability and no real fear of sudden surges, as you notice, Ryan, such "background processing" modules usually don't suffer much if some extra latency is added, as "user-facing" modules would). To choose between basic and manual scaling, consider that you're charged for (wall-clock elapsed time) 15 minutes *after* an instance is done serving its last request. So, it's not very useful if an instance goes idle (i.e is done serving its last request), shuts down say 5 minutes after going idle, then another 5 minutes later another request comes and a new instance has to spin up for the new request: you're still being charged for the instance that's shut down (and will be charged for a further 5 minutes more) PLUS the new one being spun up. It would have been a bit cheaper, as well as a bit faster, in this case, to just not let the first instance shut down -- i.e, to use manual scaling (where no automatic spin-up nor shut-down happens) rather than basic scaling. I'm mentioning this because the OP wrote about a cron job running every 5 minutes (although in that case it's not entirely clear how many instances will be needed to serve all those jobs). Alex > > @Anastasios be careful using daily budget to limit the number of > instances. When you reach the cap it will stop all traffic request and not > do any work until it resets. > > On Friday, October 23, 2015 at 1:41:00 AM UTC-4, Naresh Pokuri wrote: >> >> I have started my GAE app with *Auto-scaling* having *min-idle-instances >> 3*, each with 1GB RAM and 2.4GHz processor(i.e *F4_1G*). And I have a >> cron job which runs on every 5 minutes. With this setup keeping application >> idle for one day should equal to 72 instance hours. But I see that it >> already reached 428 instance hours. So, I am clueless here how GAE >> calculates instance hours, with this alone I can keep my budget in control. >> Can someone help me in this *instance hours* >> > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/google-appengine. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-appengine/27eb091a-b210-4d1c-86e2-1d38a143ac65%40googlegroups.com > <https://groups.google.com/d/msgid/google-appengine/27eb091a-b210-4d1c-86e2-1d38a143ac65%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CAE46Be8XDZqoBOOER3V0WKyk3vc%3D4%3D4%2B0s3jU7pWpnQ_8wd%3Dug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
