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

Question

Google App Engine提供诸如任务队列和后端(现在的模块)之类的服务,以并行处理请求和执行"并发工作".使用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提取,或者是否应该扇动-out与动态实例创建？

Answer 1

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

对，那是正确的。它实际上确实在每个实例上同时运行多个请求，而不是仅仅将它们分布在实例之间。与 Java 和 Go相同（但听起来不像 PHP）。通常认为允许这样做的最佳实践，因为它可以显着提高大多数工作负载的效率。

这个SO答案有我所见过的关于GAE如何确定是否以及何时同时运行请求的最佳细节。

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