我正在使用GAE任务队列来更新数据存储区中的批量数据。记录数约为1-2M。为此,我以这种方式安排了一个cron Job和一个队列
<queue>
<name>queueName</name>
<rate>20/s</rate>
<bucket-size>300</bucket-size>
<retry-parameters>
<task-retry-limit>1</task-retry-limit>
</retry-parameters>
<max-concurrent-requests>800</max-concurrent-requests>
</queue>
每个任务都在执行以下任务
预期添加的任务应该在667左右,但是我只能在日志中看到40个任务。
在日志中,我可以看到40秒内40个任务被添加到队列中。我在日志中没有任何错误。
有人可以帮助我了解发生了什么吗?为什么我无法添加所有任务。
谢谢
答案 0 :(得分:0)
在您的方法中,任务入队似乎与任务请求处理紧密结合,从某种意义上说,队列中对一个这样的任务的请求需要处理以入队下一个任务。因此,您需要查看可能遇到的任务处理速率限制因素。队列配置中的配置相当慷慨,但是还有其他配置。
如果您使用threadsafe
配置了应用程序,并且如果您的应用程序设计利用了它,则您的应用程序实例将能够同时处理多个请求,最多取决于其max-concurrent-requests
config和其processing latency。如果没有threadsafe
配置,则最大值为1。
实例一旦达到可同时处理的最大任务请求数,就不会开始处理队列中的新任务(因此它将不会执行步骤1-排队新任务),直到完成至少已处理的任务之一的处理为止。因此,有效地限制了每个应用程序实例的任务入队率-每个正在运行的实例只能以等于其可以并行处理的最大任务数的数量来贡献队列中的任务总数。
但是您的应用配置为自动缩放,因此一旦您设法快速“填充”所有正在运行的实例,调度程序将为其启动新实例。随着新实例的启动,它们将能够处理队列中的更多任务,从而也使新任务入队,从而为队列中的任务总数贡献了上述数量。
但是,排队任务数量的增长可能比实例没有达到其最大处理速率时要慢得多-需要花费一些时间来衡量新实例如何帮助流量来确定是否需要更多实例。队列中任务总数的总体增长将具有“阶梯”配置文件,其中步骤高度为实例可以处理的最大并发请求数,步骤数为启动的新实例数+1
由于您没有看到任何实际的任务排队错误,所以我只能怀疑您在处理排队任务时以某种方式达到了速率限制,或者以某种方式完全停止了处理。可能有很多原因,例如:
您必须从这个角度调查应用程序,以查明罪魁祸首。
旁注:我认为这是在GAE上,而不是在开发服务器上(which doesn't respect the task queue configs,并且很可能无法接近GAE的并行处理能力)。