AppEngine 任务队列 API 调用在 TaskAlreadyExistsError 上增加答案

【问题标题】：AppEngine Task Queue API Calls increase on TaskAlreadyExistsErrorAppEngine 任务队列 API 调用在 TaskAlreadyExistsError 上增加
【发布时间】：2011-08-26 12:39:03
【问题描述】：

我正在使用deferred 将任务放入AppEngine 应用程序的默认队列中，类似于this approach。

我用每 5 秒更改一次的时间戳命名任务。在此期间，许多同名的队列被调用，导致TaskAlreadyExistsError 这很好。问题是，当我检查“任务队列 API 调用”的配额时，每次调用都会增加，而不仅仅是那些实际被放入队列的调用。

我的意思是，如果您查看配额：Task Queue API Calls: 34,017 of 100,000 并与实际队列调用比较：/_ah/queue/deferred - 2.49K

这是处理队列的代码：

try:
  deferred.defer(function_call, params, _name=task_name, _countdown=int(interval/2))
except (taskqueue.TaskAlreadyExistsError, taskqueue.TombstonedTaskError):
  pass

我想这就是它的工作方式。有没有解决配额问题的好方法？我可以使用memcache存储task_name并检查除了上述try/catch之外是否添加了任务？或者有没有办法在不使用任务队列 API 调用的情况下检查任务是否已经存在？

【问题讨论】：

标签： python google-app-engine task-queue

【解决方案1】：

感谢您指出是这样的，因为我没有意识到，但同样的问题一定在影响我。

就我所见，是的，将包含任务名的内容放入 memcache 应该可以正常工作，然后如果您想减少对 memcache 的这些命中，您也可以在实例中本地存储标志。

【讨论】：

嗯，实例的东西很有趣。我可能会尝试这样做，但我可能会选择 memcache 解决方案。还是谢谢！

【解决方案2】：

解决配额问题的“好方法”是消除对任务队列 API 的注定失败的调用。

_name 您每 5 秒使用一次更改，如果您提高任务队列的执行率，这可能不会成为瓶颈。但是您也可以使用_countdown 添加任务。

【讨论】：

执行率不是问题，由memcache解决。 10 个任务/秒就足够了。问题在于，对于那些“例外”部分被击中的情况，所有不必要的任务 API 调用。