如果我threadsafe: true
在我的app.yaml
文件中设置,管理何时创建新实例来服务请求以及何时在现有实例上创建新线程的规则是什么?
如果我有一个应用程序对每个请求执行计算密集型的操作,那么多线程能给我带来什么好处吗?换句话说,实例是多核实例还是单核?
或者,新线程是否仅在现有线程等待 IO 时才启动?
如果我threadsafe: true
在我的app.yaml
文件中设置,管理何时创建新实例来服务请求以及何时在现有实例上创建新线程的规则是什么?
如果我有一个应用程序对每个请求执行计算密集型的操作,那么多线程能给我带来什么好处吗?换句话说,实例是多核实例还是单核?
或者,新线程是否仅在现有线程等待 IO 时才启动?
当前使用以下一组规则来确定给定实例是否可以接受新请求:
if processing more than N concurrent requests (today N=10): false
elif exceeding the soft memory limit: false
elif exceeding the instance class CPU limit: false
elif warming up: false
else true
以下总 CPU/核心限制当前适用于每个实例类:
CLASS 1: 600MHz 1 core
CLASS 2: 1.2GHz 1 core
CLASS 4: 2.4GHz 1 core
CLASS 8: 4.8GHz 2 core
因此,只有一个B8
实例可以并行处理最多 2 个完全 CPU 绑定的请求。
为实例类 < 8设置threadsafe: true
(Python) 或<threadsafe>true</threadsafe>
(Java) 将不允许在单个实例上并行处理多个 CPU 绑定请求。
如果您没有完全受 CPU 限制或执行 I/O,Python 和 Java 运行时将生成新线程来处理最多 10 个并发请求的新请求threadsafe: true
还要注意,即使 Go 运行时是单线程的,它也支持并发请求:它会为每个请求生成 1 个 goroutine,并在执行 I/O 时在 goroutine 之间产生控制。
阅读Kyle Finley 建议的链接中的下一条消息
Jeff Schnitzer:还有 10 个线程的硬性限制吗?
是的,但可能不是出于您期望的原因。我们遇到的主要问题是内存管理。如果我们将默认值提高到 100,那么许多应用程序会看到内存不足的死亡(比现在更多),并且这些死亡对于 python/java/go 的表现不同。正确的前进道路是更智能的算法 wrt 内存,提供可配置性等等。这是我们为调度程序工作的项目类型的一个示例,但与任何团队一样,我们必须优先考虑我们的项目。我建议在公共问题跟踪器上提交此(或任何其他所需的调度程序增强功能),以便他们可以获得反馈/数据/投票。
如果我在 app.yaml 文件中设置 threadsafe: true ,那么管理何时创建新实例来服务请求以及何时在现有实例上创建新线程的规则是什么?
就像人们在这里所说的那样,如果以前的实例已经使用了 10 个线程,那么将启动一个带有新线程的新实例。如果所有其他线程都忙,则将创建一个新线程,它们必须等待一些响应或计算结果。
如果我有一个应用程序对每个请求执行计算密集型的操作,那么多线程能给我带来什么好处吗?换句话说,实例是多核实例还是单核?
现在这个问题非常有争议。每个人都知道答案,但他们仍然持怀疑态度。如果您的任务仅基于计算,那么多线程永远不会给您带来任何好处,除非您使用的是多核处理器,不要问我为什么多核处理器会更好,您知道答案。现在,谷歌应用引擎还不够复杂,无法决定何时将新线程分派到另一个处理器/核心(如果存在),只有新实例才会分派到另一个核心/处理器。希望您的线程在其他核心/处理器中运行?好吧,在那里扔一些技能和booya!请记住,由您决定线程是否应该在其他内核/处理器中运行,引擎不能对此负责,因为这可能会导致很多混乱,引擎不是上帝。简而言之,
或者,新线程是否仅在现有线程等待 IO 时才启动?
我的答案的第一部分清除了这一点。是的,它们仅在现有线程忙碌时才启动,这就是线程安全的工作方式,以防止死锁。
现在我可以告诉你这一切,根据我的个人经验,我在应用程序引擎上工作了好几个月,并且对高度依赖于线程安全架构的应用程序进行了编程/调试/测试。如果你想我可以添加引用(我没有引用,只是个人经验,但我已经准备好为你搜索并把东西放在桌面上),但我认为在这种情况下不需要它们,线程安全以明显的方式工作,我已经验证了自己。