应用引擎调度程序何时使用新线程而不是新实例？

Question

如果我在app.yaml文件中设置threadsafe: true，那么控制何时创建新实例以服务于请求，而不是在现有实例上创建新线程的规则是什么？在

如果我有一个应用程序对每个请求执行一些计算密集型的操作，多线程对我有什么好处吗？换句话说，实例是多核实例还是单核实例？在

或者，新线程是否只有在现有线程等待IO时才会启动？在

Answer 1

If I set threadsafe: true in my app.yaml file, what are the rules that govern when a new instance will be created to serve a request, versus when a new thread will be created on an existing instance?

就像人们在这里说的，如果前一个实例已经在使用10个线程，那么将启动一个具有新线程的新实例。如果所有其他线程都很忙，那么将创建一个新线程，它们必须在等待响应或计算结果。在

If I have an app which performs something computationally intensive on each request, does multi-threading buy me anything? In other words, is an instance a multi-core instance or a single core?

现在这个问题很有争议。每个人都知道答案，但他们仍然持怀疑态度。如果任务只是基于计算，多线程永远不会给你带来任何好处，除非你使用多核处理器，不要问我为什么多核处理器会有更好的帮助，你知道答案。现在googleappengine还不够成熟，不足以决定何时应该将新线程调度到另一个处理器/核心（如果存在的话），那么只有新的实例被调度到另一个核心/处理器。希望线程在另一个内核/处理器中运行？好吧，把一些技能扔到那里去吧！记住，线程是否应该在其他内核/处理器中运行取决于您自己，引擎不能对此负责，因为这可能会导致许多混乱，引擎不是上帝。简而言之，默认情况下实例是单核的，引擎不能为您决定何时应该使用多核。在

Or, are new threads only spun up when existing threads are waiting on IO?

我的回答的第一部分澄清了这一点。是的，它们只在现有线程繁忙时才启动，这就是线程安全的工作原理，以防止死锁。在

现在我可以告诉你，从我个人的经验来看，我在appengine上工作了好几个月，编程/调试/测试了高度依赖于线程安全架构的应用程序。如果你愿意，我可以添加推荐信（我没有推荐信，只有个人经验，但我已经准备好为你搜索并把东西放在桌面上），但我不认为在这种情况下需要它们，threadsafe的工作方式显而易见，我已经验证过了。在

Answer 2

以下规则集当前用于确定给定实例是否可以接受新请求：

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/核心总限制当前适用于每个实例类：

^{pr2}$

因此，只有一个B8实例可以并行处理多达2个完全占用CPU的请求。在

为实例类设置threadsafe: true（Python）或<threadsafe>true</threadsafe>（Java）将不允许在单个实例上并行处理多个CPU绑定请求。在

如果您没有完全绑定到CPU或执行I/O，Python和Java运行时将生成新线程，用threadsafe: true处理最多10个并发请求

还要注意，即使Go运行时是单线程的，它也支持并发请求： 它将为每个请求生成1个goroutine，并在goroutine执行I/O时在goroutine之间提供控制

Answer 3

阅读来自link的下一条消息，这是凯尔·芬利建议的

Jeff Schnitzer: Is there still a hard limit of 10 threads?

Yes, but probably not for the reason you expect. The primary issue we run into is memory management. If we raised the default to 100, many apps would then see out-of-memory deaths (more than they do now), and these deaths show up differently for python/java/go. The right path forward is more intelligent algorithms wrt memory, providing configurability, and so on. This is an example of the kinds of projects we work on for the scheduler, but as with any team we have to prioritize our projects. I'd recommend filing this (or any other desired scheduler enhancements) on the public issue tracker so they can get feedback/data/votes.