Google App Engine - throttle_code = 4 unter hoher Belastung im Belastungstest

Question

Ich führe einige Lasttests mit JMeter durch, um eine Vorstellung davon zu bekommen, wie meine Anwendung unter Last auf Google App Engine (Java) funktioniert.

Wenn ich getroffen rund 100 virtuelle Nutzer meine Reaktionszeit beginnt fallen, und ich merke, „throttle_code = 4“ in den Protokolldateien GAE erscheinen (siehe unten).

Wer weiß, was das bedeutet? Ist die Tatsache, dass ich mehrere Anfragen von der gleichen IP schlägt eine Art automatischen DDOS Schutzes machte?

Dank

 
---- request with"throttle_code=4"; when connecting from JMeter 
07-05 05:11AM 58.917 /market/1234/history?pricebars=240 200 3651ms 19cpu_ms 35kb Java/1.5.0_16,gzip(gfe) 
75.101.226.4 - - [05/Jul/2010:05:12:02 -0700] "GET /market/1234/history?pricebars=240 HTTP/1.1" 200 35566 - "Java/1.5.0_16,gzip(gfe)" "ci-pricehistory.appspot.com" ms=3652 cpu_ms=19 api_cpu_ms=0 cpm_usd=0.004527 pending_ms=3570 throttle_code=4 
I 07-05 05:12AM 02.532 
uk.co.cityindex.CandleServlet fetch: Loading 240 bars from cache... 
I 07-05 05:12AM 02.558 
uk.co.cityindex.CandleServlet fetch: time:47 

---- request without "throttle" log; when connecting from browser 
07-05 06:28AM 10.993 /market/1234/history?pricebars=240 200 69ms 19cpu_ms 7kb Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4,gzip(gfe) 
80.169.172.178 - - [05/Jul/2010:06:28:11 -0700] "GET /market/1234/history?pricebars=240 HTTP/1.1" 200 7572 - "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4,gzip(gfe)" "ci-pricehistory.appspot.com" ms=69 cpu_ms=19 api_cpu_ms=0 cpm_usd=0.001423 
I 07-05 06:28AM 11.031 
uk.co.cityindex.CandleServlet fetch: Loading 240 bars from cache... 
I 07-05 06:28AM 11.055 
uk.co.cityindex.CandleServlet fetch: time:45 

Answer 1

See (scheinbar) offiziell Google hier beantworten, obwohl ich es total beantwortet die Frage nicht sicher bin.

Es sieht so aus, als ob Ihre Anfrage 3500ms dauert. Wir automatisch skaliert, um die Anzahl der Instanzen, die Wartung Ihre Anfragen so lange wie Sie Durchschnitt Millisekunden/Anforderung von 1000 ms erhalten oder unter (wir empfehlen 800ms, 400ms Unter optimal ist). Wenn Sie viele lange Lauf Anfragen laufen, werden wir keine neuen Instanzen für Sie spin up und Sie werden eine Skalierung Decke getroffen.

http://osdir.com/ml/GoogleAppEngine/2010-07/msg00165.html

Offenbar drosseln sie auf der Grundlage der Leistungsfähigkeit ", aber es sieht aus wie Ihre ursprüngliche Anfrage nur 69ms war. War die durchschnittliche ms/req Ihrer App aufgrund anderer Anfragen höher? Es scheint wie eine seltsame Taktik spin up nicht, weil Ihre Anwendung ist langsam, wenn Ihre Anwendung ist langsam, weil es noch nicht hochgedreht hat ...

Das andere, was ich bemerken ist, dass Ihre Testanforderung durch JMeter ist 35kb vs die 7kb der anderen Anfrage - erhöhen sich die Daten Ihrer App unter Testlast? Kopfzeilen häufen sich?