Idle Dynamic Instance

[Paul Spychala]

App Engine Release	Total number of instances	Average QPS*	Average Latency*	Average Memory
1.9.24	2 total	9.010	55.5 ms	64.0 MBytes

Instances 

QPS*	Latency*	Requests	Errors	Age	Memory	App Engine Release	Logs	Availability	Shutdown
0.000	0.0 ms	28	0	2:52:01	56.8 MBytes	1.9.24	View Logs	Dynamic
17.713	55.5 ms	5394	3	14:56:05	71.1 MBytes	1.9.24	View Logs	Dynamic

* QPS and latency values are an average over the last minute.

I get many days where there seems to be a idle Dynamic instance thats hardly doing any work thats eatting into my instance-hours. I use the default Module settings and don't have anything else customized, so is there a good way to check why this happens? I'm fine if an instance starts up when traffic spikes however ~28 requests doesn't feel like a traffic spike to me.

[Patrice (Cloud Platform Support)]

Hi Paul,

Do you mind including your yaml? The scaling you're using (you say "default Module settings", but I'd like to make 100% sure about them). It's possible, with an average of 55,5 ms latency, that the system decided to spin up a new instance because it didn't want that number to go higher.

Automatic scaling does have a tendency to aggressively scale and spin up instances preventively. You have to understand that it assumes your app to grow in requests, so if it sees that all of a sudden, an instance receives 100 requests, the system will assume that your instance will continue to get MORE (so 100 in a minute means that, in 5 minutes, you'll be receiving 500 requests a minute), and spins up more instances to accommodate the load.

You can read more about this here, and with your yaml, I may be able to give you more information as to what exactly happened, but if you're using the automatic scaling, chances are this is the culprit here.

Cheers!

[Paul Spychala]

	version: 2
	runtime: python27
	api_version: 1
	threadsafe: true
	handlers: - url: .. lots of handlers
	- url: /.*
	script: main_controller.app
	libraries:
	- name: webapp2
	version: 2.5.2
	- name: jinja2
	version: 2.6

There really isn't anything here worth mentioning, its all default

[Patrice (Cloud Platform Support)]

Hi Paul,

Thanks for including that, this was just to make sure everything was okay, just in case.

Since you're using the fully default, I think this behavior is actually expected. I would suggest changing a couple of parameters from the default to make sure that this behaves properly.

Mainly, you can increase the "min_pending latency", "max_pending_latency" and "max_concurrent_request", since the default numbers don't really work out for your use case. 

It'll be hard to give you precise numbers since they can vary greatly, but I'd definitely look into putting a higher number than the default on these. You might need to tweak it over the course of a couple of days to get the precise balance of latency/cost you want.

Cheers!