Google App Engine 用于长时间运行但 CPU 较低的任务，还是长时间轮询？

Question

App Engine 非常适合快速处理请求，无需对数据库或缓存或第三方资源进行外部 API 调用，但我们发现引入任何类型的“更长时间运行”组件或外部延迟（例如在一个在后台异步运行的 HTTP POST 操作，可能需要一两秒钟来处理一些更密集的数据库查询......从客户端的 UX 角度来看完全不可见并且可以，因为它是异步的，但对 App Engine 计费来说很昂贵因为它运行时间很长）......“实例时间”复合并大大增加了成本。

在这种情况下，请求实际上只是在等待来自外部资源的响应，并且在空闲期间需要几乎零 CPU 似乎可以避免，但我不确定它是否可以避免使用 App Engine。

这几乎就像一个“长期投票”，响应可能会保持打开状态但什么也不做。

有没有一种方法可以在 App Engine 上做到这一点，而无需支付大量的实例时间，或者我们是否会更好地迁移到 Compute Engine 或 EC2？它是根据 CPU 负载自动扩展，还是仅基于打开的和可能不活动的请求总数？ — threadsafe 确实已启用。

Answer 1

实际上有两种方法可以解决这个问题（最重要的是）。

使用任务队列！

如果工作不需要与请求完全相同，这正是 App Engine 中的 [任务队列] 的用途。它们允许您将工作放在队列中，并让另一个模块接手工作。它们非常棒，因为您可以单独扩展前端和后端流程。

如果这不起作用......

灵活使用 App Engine

在后台App Engine Flexible 只是在运行 GCE 实例。成本结构完全不同，因为您始终有一个在后台运行的 VM 为您的请求提供服务。

希望这会有所帮助！

Answer 2

您真正担心的是 App Engine scales 您的实例如何。由于您的许多请求需要很少的资源，因此您的应用程序可能能够在单个实例上处理比正常情况更多的并发请求。您可以查看形状缩放的参数here。特别感兴趣：

ma​​x_concurrent_requests 在调度程序生成新实例之前，自动扩展实例可以接受的并发请求数（默认值：8，最大值：80）。

这里有一个危险，实例可能会被非长轮询请求填满并变得负担过重。为防止这种情况，您可以将长轮询请求隔离到它们自己的 service 中，并将其缩放参数与应用程序的其余部分分开设置。