Google App Engine - 在负载测试中处于高负载时throttle_code=4
我正在使用 JMeter 运行一些负载测试，以了解我的应用程序在 Google App Engine (Java) 负载下的执行情况。
当我达到大约 100 个虚拟用户时，我的响应时间开始下降，并且我注意到 GAE 日志文件中出现“throttle_code=4”（见下文）。
有谁知道这意味着什么？我从同一个 IP 发出多个请求是否会遇到某种自动 DDOS 保护？
谢谢
---- 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
I'm running some load tests using JMeter to get an idea of how my application performs under load on Google App Engine (Java).
When I hit around 100 virtual users my response time starts dropping, and I notice "throttle_code=4" appearing in the GAE log files (see below).
Does anyone know what this means? Is the fact that I'm making multiple requests from the same IP hitting some kind of automatic DDOS protection?
Thanks
---- 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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
请参阅（显然）此处的官方谷歌答案，尽管我不确定它是否完全回答了问题。
http://osdir.com/ml/GoogleAppEngine/2010-07/msg00165。显然
，他们根据你的“效率”进行限制，但看起来你的原始请求只有 69 毫秒。您的应用程序的平均毫秒数/请求数是否可能因其他请求而更高？这似乎是一个奇怪的策略，因为你的应用程序很慢，因为你的应用程序很慢，因为它还没有启动...
我注意到的另一件事是，你通过 JMeter 的测试请求是 35kb，而另一个是 7kb请求 - 您的应用程序的数据在测试负载下是否会增加？标题堆积？
See (apparently) official Google answer here, though I'm not sure it totally answers the question.
http://osdir.com/ml/GoogleAppEngine/2010-07/msg00165.html
Apparently, they throttle based on your 'efficiency,' but it looks like your original request was only 69ms. Was your app's average ms/req higher because of other requests, possibly? It seems like a weird tactic NOT spin up because your app is slow if your app is slow because it hasn't yet spun up...
The other thing I notice is that your test request through JMeter is 35kb vs the 7kb of the other request - does your app's data increase under testing load? Headers piling up?