Google App Engine 后端/模块实例中的实际并发答案

【问题标题】：Actual concurrency in Google App Engine backend/module instancesGoogle App Engine 后端/模块实例中的实际并发
【发布时间】：2014-02-26 05:17:11
【问题描述】：

Google App Engine 提供任务队列和后端（现在的模块）等服务，以并行处理请求并执行“并发工作”。典型的 fan-in-fan-out/fork-join 技术可以通过 Pipelines API、Fantasm 等轻松实现。

在配置后端/模块的硬件时，您可以在 B1、B2、B4、B8 之间进行选择，但它并没有说明 CPU 配置中的内核数量。也许 CPU 内核的数量在这里无关紧要。后端支持为每个传入请求生成“后台线程”，但由于著名的 GIL（全局解释器锁），Python 实际上无法执行真正的并发工作。

一个前端实例在启动一个新实例之前将处理 8 个请求（默认，最多 30 个）。

据说带有 Threadsafe 指令的 Python 2.7 可以在一个隔离实例上并行处理传入请求，这是正确的，还是只是传入请求分布在以真正并发方式完成的独立实例上？

在 Google App Engine 上，从技术上讲，什么是真正的并发实际执行，另一方面，获得最真正的并发和可扩展性的推荐设计模式是什么？

您可以使用 10-20 个常驻 B8 实例创建一个“手动扩展”后端/模块，每个实例生成 10 个“过期”后台线程，并始终为 I/O 工作执行 10 个并发异步 URL 提取，或者应该它是通过动态实例创建来扇出的吗？

【问题讨论】：

如果您使用所有 api 的异步版本，则可以在 python 中执行并发处理。大多数请求最终都会使用大量的 vaious api，因此有很多并发机会，但是如果您只是执行 CPU 密集型任务，您将从单个后端或前端获得很少的并发。
您采用何种具体方法在很大程度上取决于您的处理要求，您需要进行剖析以更好地了解最合适的选择。
使用所有可用的 App Engine API 异步版本的多个实例和代码的组合将在传入请求之间提供最佳的现实生活并发。
@TimHoffman，仅供参考，异步与同步 API 之间的区别主要在于用户空间。 App Engine 的请求调度程序并不关心您使用哪一个。 It only looks at current overall CPU load. 如果当前请求在 API 调用中被阻塞，无论它们使用的是同步 API 还是异步 API，调度程序都会愉快地在该实例上运行一个新请求。

标签： python google-app-engine python-multithreading concurrent-programming

【解决方案1】：

据说带有 Threadsafe 指令的 Python 2.7 可以在一个隔离实例上并行处理传入请求，这是正确的吗？

Yes, that's correct. 它实际上确实在每个实例上同时运行多个请求，而不是仅仅将它们分散到多个实例中。 Same with Java and Go（但it sounds like not PHP）。通常认为允许这样做是最佳实践，因为它可以显着提高大多数工作负载的效率。

This SO answer 提供了我所见过的关于 GAE 如何确定是否以及何时同时运行请求的最佳详细信息。

您说得对，Python 有一个 GIL，它在一定程度上限制了跨内核的并发性，对于真正受 CPU 限制的工作负载，每个内核多个线程对您没有多大帮助。但是，绝大多数工作负载不受 CPU 限制，尤其是 GAE 等平台上的 web 应用程序。相反，它们通常受 I/O 限制，即它们大部分时间都在等待数据存储、HTTP 提取到其他服务等。App Engine 使用该阻塞时间在同一实例上有效地运行其他并发请求。

【讨论】：