不再有High CPU限制, 但还得悠着点!

上周五检查FeedzShare的"Quota Detail"时发现"High CPU requests"一项统计已经消失了, 不由得猜测是app engine team又整出一个bug还是真的取消了对高CPU的限制. 周六app engine的官方blog宣布No more "High CPU Requests"!,老冒也很快贴出了GAE去掉了该死的high CPU requests

app engine team宣称他们调整了处理request的的方式, 现在不再有每分钟只允许2个CPU密集请求的限制. 除此之外, request的timeout时间提高到30秒, 原来是10秒. 原来这两个限制是比较烦人的东西, 尤其是如果request的处理代码中有urlfetch, urlfetch花的时间也算在花费的cpu时间里面.

但 是app engine team只是调整了限制的方式, 新引入了Active Request的概念(我不记得以前有这个限制, 如果你以前看到过, 请留言告诉我). app engine的web server同时只能处理30个request. 这意味着request平均响应时间是1秒的话, 你的应用每秒只能处理30个请求. 如果你真的有一个响应时间30秒的请求的话, 那其它request就要等会了. 这很公平, 每个app有相同的资源, 你可以决定怎么分配它们, 是处理更多的请求还是每个请求做更多的事. 静态文件请求不受此限制. 具体说明请看文档

到 目前为止(16日早), Logs中cpu消耗比较高的request还是有警告, 仍然会提示"this request used a high amount of cpu.....", 不过不显示在Severity-warning了. 不知道google以后是否还会保留警告信息. 我个人希望他们能保留, 因为对tunning比较有帮助.

这次还有一个改进就是request和response的大小可以有10M了. 对发送大图片会是比较大的帮助. 不过每次api调用的大小还是1M, 意味著写入memcache的每个item还是1M.

随着这次改进, 介绍app engine quotas的文档 也更新了, 这篇文档介绍了app engine的各项配额以及配额如何计算(How Resources are Replenished), 超过配额后Google如何处理(When a Resource is Depleted), 个人推荐大家去看看.
我 在文档中发现这么一句: We will publish more information about burst limits when we release the billing feature in 2009. 随着付费版在09年发布, Google App Engine应该会摘掉Preview的帽子了吧.

kuber @FeedzShare