Google app engine 任务队列真的并行运行任务吗？_Google App Engine_Scalability_Task Queue

Google app engine 任务队列真的并行运行任务吗？

google-app-engine

Google app engine 任务队列真的并行运行任务吗？,google-app-engine,scalability,task-queue,Google App Engine,Scalability,Task Queue,我们有一个应用程序，它接受用户的一些输入，并进行约50次RPC调用。每次通话大约需要4-5分钟在后端，我们使用一个推送队列，并将这50个调用中的每一个作为任务排队。这是我们的队列规范： queue: - name: some-name rate: 500/s bucket_size: 100 max_concurrent_requests: 500 我的理解是，所有50个请求都应该并行运行，因此所有请求都应该在4-5分钟内完成。但实际发生的情况是，这些请求中只有约15个返回结果，

我们有一个应用程序，它接受用户的一些输入，并进行约50次RPC调用。每次通话大约需要4-5分钟

在后端，我们使用一个推送队列，并将这50个调用中的每一个作为任务排队。这是我们的队列规范：

queue:
- name: some-name
  rate: 500/s
  bucket_size: 100
  max_concurrent_requests: 500

我的理解是，所有50个请求都应该并行运行，因此所有请求都应该在4-5分钟内完成。但实际发生的情况是，这些请求中只有约15个返回结果，而其余的请求超过了10分钟的限制并超时。另一件需要注意的事情是，如果我们将请求数降低到<10，那么这似乎可以正常工作

由于RPC响应实际花费了那么长时间，所以超时的请求总是有可能超时。但我想确认的是：

我对并行运行的任务的理解是正确的

我们的队列配置和排队的任务数与这些请求超时无关。这些是正确的吗

（1）并行执行是的，任务可以并行执行（在您的情况下最多可执行500个），但在推送队列中，您的应用程序无法控制推送队列中任务的执行顺序，也无法直接控制一次执行多少任务。（不过，您的应用程序可以控制向队列中添加任务的顺序，请参见下面（2）中的模式）

App Engine使用某些因素来决定执行任务的速度和类型，尤其是队列配置和缩放配置（例如在

App.yaml

）。由于您要为实例的前15分钟付费，因此真正启动50个实例，然后在关闭它们之前闲置15分钟（直到下一个请求）可能会非常昂贵。在这方面，生成新实例的机制稍微聪明一些，无论是用户的HTTP请求还是任务队列

（2）请求超时是的，排队不太可能与这些请求超时有关。除非超时是之前执行过特定任务的错误假设的无意副作用

一般来说，为了避免请求超时，将一个任务拆分为多个任务是有意义的。例如，如果您有一个任务

do_foo

，并且这些执行经常超过超时时间（或内存限制），那么您可以让

do_foo

将工作加载到将执行实际作业的其他任务

对于某些迁移任务，我以线性/顺序的方式使用此模式。例如，classmethod

do_foo

只查询特定类型的实体（例如按创建时间戳排序），可能按页面过滤（例如，在与祖先的事务中为50）。它首先对实体执行一些写入操作，只有在成功提交后的最后，它才会创建一个新的事务性

do_foo

任务，并将游标参数带到下一页，最后倒计时1秒以避免事务错误。下一次执行

do_foo

将继续执行下一页（当然，只有在完成上一页的任务之后）

根据任务的性质，您也可以让每个任务在每次执行时分成多个任务，例如

do\u foo

触发器

do\u bar

，

do\u something

和

do\u more

。还请注意，在一个事务中最多可以事务性地创建五个任务。