我们有一个应用程序从用户那里获取一些输入并进行~50次RPC调用。每次通话大约需要4-5分钟。
在后端，我们使用推送队列并将这50个调用中的每一个作为任务排队。这是我们的队列规范：
queue:
- name: some-name
rate: 500/s
bucket_size: 100
max_concurrent_requests: 500
我的理解是所有50个请求应该并行运行，因此所有这些请求应该在4-5分钟内完成。但实际发生的事情是，这些请求中只有大约15个返回结果，而其余请求超过10分钟限制和超时。另一件需要注意的事情是，如果我们将请求数量减少到＆lt; 10。
由于RPC响应实际上花了那么长时间，因此超时请求总是存在这样的可能性。但我想证实的是：
答案 0 :(得分：0)
是的，任务可以并行执行（在您的情况下最多500个），但在推送队列中，您的应用无法控制执行推送队列中的任务特定订单没有直接控制一次执行多少任务。 （您的应用程序可以控制将任务添加到队列的顺序，请参阅下面（2）中的模式）
App Engine使用某些因素来决定执行的速度和执行速度，尤其是队列配置以及缩放配置（例如，在app.yaml中）。由于您为实例的前15分钟付费，实际启动50个实例可能会非常昂贵，然后在关闭它们之前空闲15分钟（直到下一个请求）。在这方面，产生新实例的机制更聪明，无论是用户的HTTP请求还是任务队列。
是的，排队与这些请求超时有关的可能性很小。除非超时是以前执行特定任务的错误假设的无意的副作用。
为了避免一般的请求超时，将任务拆分为多个任务是有意义的。例如，如果您有一个任务do_foo并且这些执行超出了超时（或内存限制），您可以将do_foo加载到其他将执行实际工作的任务。< / p>
对于某些迁移任务，我以线性/顺序方式使用此模式。例如。 classmethod do_foo只查询某种类型的实体（例如按创建时间戳排序），可以按页面过滤（例如，与祖先交易中的50）。它首先对实体进行一些写操作，并且仅在成功提交后的最后，它创建一个新的事务do_foo任务，其中游标参数到下一页，最终倒计时为1秒，以避免交易错误。 do_foo的下一次执行将继续下一页（当然只有在完成上一页的任务之后）。
根据任务的性质，您可以将每个任务分散到每个执行的多个任务中，例如， do_foo会触发do_bar，do_something和do_more。另请注意，在事务中可以事务性地创建最多五个任务。