App Engine：time.sleep() 是否会计入我的配额？
嘿。我正在开发一个 App Engine 应用程序，该应用程序涉及对 Google Maps API 进行地理编码的查询。 Google 地图不喜欢太多请求，因此我使用 time.sleep(1) 在每个请求之间设置 1 秒的延迟。
我注意到我的 GAE 仪表板中的配额不足，因此决定运行一个简短的测试：
import cProfile
import time
def foo():
time.sleep(3)
cProfile.run('foo()')
这给了我以下输出：
4 function calls in 3.003 CPU seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 3.003 3.003 <stdin>:1(foo)
1 0.000 0.000 3.003 3.003 <string>:1(<module>)
1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects}
1 3.003 3.003 3.003 3.003 {time.sleep}
因此它表示 time.sleep(3) 消耗了 3 CPU 秒。现在我想知道这样的调用是否计入 GAE 提供的配额限制。如果确实如此，那么在地理编码的 API 调用之间造成延迟的其他方法是什么？
谢谢。
Hey. I'm working on an App Engine app that involves queries to the Google Maps API for geocoding. Google Maps doesn't like too much requests so I put a 1 second delay between each request with time.sleep(1).
I noticed that my quotas are running low in my GAE dashboard and decided to run a short test:
import cProfile
import time
def foo():
time.sleep(3)
cProfile.run('foo()')
Which gave me the following output:
4 function calls in 3.003 CPU seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 3.003 3.003 <stdin>:1(foo)
1 0.000 0.000 3.003 3.003 <string>:1(<module>)
1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects}
1 3.003 3.003 3.003 3.003 {time.sleep}
So it says that it's consuming 3 CPU seconds for a time.sleep(3). Now I'm wondering if calls like these are counted towards the quota limits that GAE provides. And if it does, what is the other way of making delays between API calls for geocoding?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您当然不想尝试在一个完全从头开始设计的系统中睡觉，以便在绝对最短的时间内完成请求：D
相反，您可以做的是为每个地理编码创建一个任务，（查看延迟库）。您需要为此任务指定一个队列，然后只需将队列的速率限制设置为您认为地图地理编码器可能满意的值即可。
这样，每个地理编码都会运行，并且您永远不会超过您设置的速率限制，并且不需要进行任何管道操作。
You certainly don't want to be trying to sleep in a system that's designed completely from the ground up to finish requests in the absolute shortest time possible :D
What you could do instead, is create a task for each geocode, (check out the deferred library). You'd want to specify a queue for this task, then just set the rate limit on the queue to whatever you feel the maps geocoder might be comfortable with.
This way every geocode will run, and you'll never go faster than the rate limit you set, and you don't need to do any plumbing.
我相当确定队列任务也会计入 GAP 中的 CPU 使用率。关于
sleep()，我认为不会因此而产生 CPU“惩罚”，但我认为这是一种糟糕的风格。为什么要睡觉？在您的任务中，执行一次地理编码，然后在 3 秒内将另一个调用发布到队列中。请参阅调用http://code.google.com/intl/el/appengine/docs/python/taskqueue/functions.html#add 。
I am fairly certain that queue tasks also count towards your CPU usage in GAP. Regarding
sleep(), i don't think there will be CPU "penalty" from that but I think it's a bad style.Why sleep at all? In your task, do a single geocoding and simply post another invocation to yourself in the queue in 3secs. See the parameter
countdownWhen invoking http://code.google.com/intl/el/appengine/docs/python/taskqueue/functions.html#add .您的实验证明 time.sleep 时间会占用您的配额。查看实验性Task Queue API 。如果您的任务不是由用户启动的，您还可以使用 Cron 任务，但我不知道这是否能在如此小的间隔内正常工作。
Your experiment proves that the time.sleep time counts against your quota. Have a look at the experimental Task Queue API. If your task isn't user initiated, you could also use Cron tasks, but I don't know if this will work well with so small intervals.
此问题报告报告者尚未按 CPU 秒数付费由 time.sleep() 引起，但它们显示在应用程序统计中。 appstats 很可能也使用 cprofile。睡眠对于尝试制作更好的异步代理的人来说非常重要，他可以使用异步代理对更大的项目集进行地理编码。
http://code.google.com/p/googleappengine/issues/detail ?id=3291
This Issue reports that the reporter has not been billed for cpu seconds incurred by time.sleep(), but that they show up on their appstats. It is very likely appstats uses cprofile as well. Sleep is important for people trying to make better asyncronous proxies which he could use for geocoding larger set of items.
http://code.google.com/p/googleappengine/issues/detail?id=3291