Google app engine 为非紧急工作配置任务队列和实例

我正在使用一个F4实例（因为内存需要）和自动调度来做一些后台处理。它从任务队列运行。完成每次调用需要40到60秒。由于内存需求很大，每个实例一次只能处理一个请求

需要采取的行动并不紧迫。如果30分钟内没有安排，那不是问题。即使是60分钟也是可以接受的，我宁愿利用这段时间，也不愿制造更多的实例。但是，如果该服务变得流行，并且每小时收到的请求超过60个，我希望增加更多实例，以确保等待时间不会超过60分钟

我很难弄清楚如何配置实例和队列参数以降低成本，但能够以这种方式扩展。我最初的想法是这样的：

<queue>
    <name>non-urgent-queue</name>
    <target>slow-service</target>
    <rate>1/m</rate>
    <bucket-size>1</bucket-size>
    <max-concurrent-requests>1</max-concurrent-requests>
</queue>


<automatic-scaling>
    <min-idle-instances>0</min-idle-instances>
    <max-idle-instances>0</max-idle-instances>
    <min-pending-latency>20m</min-pending-latency>
    <max-pending-latency>1h</max-pending-latency>
    <max-concurrent-requests>1</max-concurrent-requests>
</automatic-scaling>

<queue>
    <name>slow-queue</name>
    <target>pdf-service</target>
    <rate>2/m</rate>
    <bucket-size>1</bucket-size>
    <max-concurrent-requests>1</max-concurrent-requests>
  </queue>
<queue>
    <name>fast-queue</name>
    <target>pdf-service</target>
    <rate>10/m</rate>
    <bucket-size>1</bucket-size>
    <max-concurrent-requests>5</max-concurrent-requests>
</queue>

<automatic-scaling>
   <min-idle-instances>0</min-idle-instances>
   <max-idle-instances>automatic</max-idle-instances>
   <min-pending-latency>15s</min-pending-latency>
   <max-pending-latency>15s</max-pending-latency>
   <max-concurrent-requests>1</max-concurrent-requests>
</automatic-scaling>

非紧急队列
慢服务
1/m
1.
1.
0
0
20米
1h
1.

首先，这些延迟设置无效，但我找不到有关有效范围或单位的文档。有人能告诉我那个信息吗

其次，如果我正确理解了队列设置，那么即使任务队列中有60多个作业等待，这种配置也会将到达服务的时间限制为每小时60次调用

---

谢谢你的帮助

事实上，队列级别的节流基本上破坏了在需要时进行扩展的能力。因此，您不能在队列配置中以当前的值使用

，您需要使用与您愿意接受的最大速率相匹配的值（同时运行的最大实例数）：

• 可以通过队列的最大请求速率限制为1/min，这意味着您不能扩展到60/h以上

• 设置为

  1

  的
  意味着不能处理高于速率的峰值（只要一个任务启动，令牌桶就会清空）

• 设置在

  1

  的
  基本上可以防止多个实例同时处理排队的工作负载。由于请求延迟，它们可能由autoscaler启动，但它们无法提供帮助，因为一次只能处理一个队列任务

在

部分中，将

设置为

1

是好的-这确保没有实例一次处理超过1个请求-这正是您想要的

坏消息是延迟的最大值似乎是15秒。至少在使用python的

app.yaml

config时是这样（但我认为这不太可能在不同语言的沙盒中有所不同）：

及

这可能也解释了为什么您的

5m

和

1h

值不被接受-我使用了

30s

和

60s

，并得到了上述错误

这意味着您将无法使用自动缩放参数来调整如此缓慢的处理过程

我能想到的唯一选择是有两个队列：

• 快速输入只会触发慢速服务作业的任务，但您的服务会截取这些任务并将其保存在数据存储中。可能由一些更快的服务执行（您不希望这些服务被卡在缓慢的服务作业执行后面，因为这可能会导致不必要的实例启动。可能，根据您的实现的其余部分，您可以完全替换此队列，只需将作业信息存储在数据存储中，而不需要在快速队列中分配任务
• 用于实际慢速服务作业执行任务的慢速作业

---

您还可以让一个cron作业每分钟执行一次，检查数据存储中有多少触发器处于挂起状态，决定在慢速队列中扩展和排队相应数量的慢速服务作业任务的数量。autoscaler只需显示相应数量的实例（如果需要）。在这种情况下，需要低延迟自动缩放配置-您已经决定了您的应用程序的缩放方式。

我就是这样完成的。我使用一个慢队列和一个快速队列，配置如下：

<queue>
    <name>non-urgent-queue</name>
    <target>slow-service</target>
    <rate>1/m</rate>
    <bucket-size>1</bucket-size>
    <max-concurrent-requests>1</max-concurrent-requests>
</queue>


<automatic-scaling>
    <min-idle-instances>0</min-idle-instances>
    <max-idle-instances>0</max-idle-instances>
    <min-pending-latency>20m</min-pending-latency>
    <max-pending-latency>1h</max-pending-latency>
    <max-concurrent-requests>1</max-concurrent-requests>
</automatic-scaling>

<queue>
    <name>slow-queue</name>
    <target>pdf-service</target>
    <rate>2/m</rate>
    <bucket-size>1</bucket-size>
    <max-concurrent-requests>1</max-concurrent-requests>
  </queue>
<queue>
    <name>fast-queue</name>
    <target>pdf-service</target>
    <rate>10/m</rate>
    <bucket-size>1</bucket-size>
    <max-concurrent-requests>5</max-concurrent-requests>
</queue>

<automatic-scaling>
   <min-idle-instances>0</min-idle-instances>
   <max-idle-instances>automatic</max-idle-instances>
   <min-pending-latency>15s</min-pending-latency>
   <max-pending-latency>15s</max-pending-latency>
   <max-concurrent-requests>1</max-concurrent-requests>
</automatic-scaling>

慢队
pdf服务
2/m
1.
1.
快速队列
pdf服务
10/米
1.
5.

慢速队列中的最大并发请求数确保一次只运行一个任务，因此只有一个实例处于活动状态

在我发布到慢速队列之前，我会检查队列中已经有多少项。结果可能不完全可靠，但就我而言已经足够了。在java中：

QueueStatistics queueStats = queue.fetchStatistics();
if(queueStats.getNumTasks()<30) { 
   //post to slow queue
} else {
   //post to fast queue
}

QueueStatistics queueStats=queue.fetchStatistics（）；
if（queueStats.getNumTasks（）感谢您确认队列设置的作用以及有关自动缩放参数范围的信息。两个队列的想法很有趣。我仍在努力解决这个问题。cron作业给了我另一个尝试操纵队列速率的想法。看起来好像有某种队列管理api被弃用了，而新的api没有还没有，所以不确定这是否可能。。。。