Naresh, your assumption is right, that one of the idle instances is taking up the load. That's the purpose of an idle instance: to quickly take up load, with-out the time-delay that is added by starting up a new instance.
*But,* while that instance is processing the request, it is *not idle anymore*. You have defined that you want *at least three idle* instances, so a fourth instance will be started, as soon as one of the instance isn't idle anymore. Let's see an example: 1. 09:00:00 instance #1: idle, instance #2: idle, instance #3: idle (total idle: 3, total instances: 3) 2. now cron-job request comes in, so it is assigned to one of your idle instances (let's assume your cron-job doesn't spawn many tasks in parallel, it's just one single request... result: 3. 09:00:01 instance #1: utilized with your cron-job, instance #2: idle, instance #3: idle (total idle: 2, total instances: 3) GAE will start another instance, because there are only two idle instances left, but you defined min-idle-instances: 3 4. 09:00:10 instance #1: utilized with your cron-job, instance #2: idle, instance #3: idle, instance #4: idle (total idle: 3, total instances: 4) 5. 09:00:41 now let's assume your cron-job finished (i.e. request took 40 seconds) 6. 09:00:42 instance #1: idle, instance #2: idle, instance #3: idle, instance #4: idle (total idle: 4, total instances: 4) because you have defined that you want at most 3 idle instances, GAE will immediately shutdown one of the idle instances 7. 09:00:43 instance #1: idle, instance #2: idle, instance #3: idle (total idle: 3, total instances: 3) Because you have defined max-idle-instances, GAE is more aggressive in shutting down idle instances (see Ryan's post). The default behavior would be to shut down after 15 minutes of inactivity. At 09:05:00 the same behavior as above will repeat. You will again have a forth instance started, and at the end one of the idle instances will be killed too early, so at 09:10 the same, and so forth. As Alex mentioned, each instance will always be billed for at least 15 minutes, even so an instance was only idle/active for a few seconds or minutes. So, your max-idle-instances will cost you even more in the example earlier. If there were no max, GAE would let an idle instance live for the default of 15 minutes. But your next request comes already every 5 minutes, so it wouldn't shutdown an instance only to restart another one soon after, billing you both. Based on your descriptions, I think that you don't need any idle instances, because your app only does the one cron-job, and typically a cron-job can wait for any start-up time (which is unlikely in a 5 minute schedule anyway). But I can only assume, which configuration would make sense for your app or this module, there are many questions left (e.g. if your app serves end-users, if start-up time for cron-jobs is tolerable, how many requests are caused per cron-job, how long do these requests run). On Sunday, October 25, 2015 at 1:37:00 PM UTC+1, Naresh Pokuri wrote: > > 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. > > > So, why GAE spins up 4th instance when I have three Idle instances to > address the load. For one QA I have deployed app and load will be very > less. In that case I feel that those idle instance can take up the load I > feel. > > On Friday, 23 October 2015 19:13:21 UTC+5:30, Ryan (Cloud Platform > Support) 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. 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. >> >> @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* >>> >> -- HATZIS Edelstahlbearbeitung GmbH Hojen 2 87490 Haldenwang (Allgäu) Germany Handelsregister Kempten (Allgäu): HRB 4204 Geschäftsführer: Paulos Hatzis, Charalampos Hatzis Umsatzsteuer-Identifikationsnummer: DE 128791802 GLN: 42 504331 0000 6 http://www.hatzis.de/ -- 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/7ab6af15-531f-4747-8c28-f5f52bb50528%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
