这是我的第一篇文章，我是数据库管理员，并希望使用Play框架版本2.4。我已经阅读了play 2文档，但仍然有一些问题，因为我对它很新。我有一个消息传递系统，需要每秒处理多达50,000个阻塞线程的负载。如果我是正确的，可用的最大线程数如下：
Parallism-Factor * AvailableProcessors
Parallism-Factor是每个核心可以使用的线程数量？我已经看到大多数例子都有这个数字为1.0出现在100左右的错误是什么？我现在将这个P因子设置为10.0并且我有150个cpu核心，这意味着如果是这样的话我最多可以有1,500个线程，并且我必须每秒处理多达50,000个阻塞请求然后系统会非常慢吗？所以扩展的唯一方法是添加更多核心，因为所有请求都是阻塞的？
答案 0 :(得分：0)
为异步编程创建了Play。这就是并行因子为1.0的原因。当您执行大量小而快速的非阻塞算法时，这是最佳选择。
问题是你是什么意思＆＃34; 50,000阻塞线程每秒＆＃34;。阻止可能会有所不同。最常见的阻塞示例是访问RDBMS。我很确定在这种情况下，你的系统可以像魅力一样处理50000阻塞数据库访问。
Play Thread Pool文档中的示例说，对于使用阻塞数据库调用的应用程序，并行因子为300可以很好，因此150 * 300 = 45 000 - 几乎是您的数字。
答案 1 :(得分：0)
'每秒50,000个阻止请求'并不意味着您需要50,000个线程来处理它们。每个数据库调用都不需要一个线程。
进行一个非常简单的计算：每个数据库调用需要0.1秒，这是一个任意数字，因为我不知道你的调用需要多长时间。这50.000个请求中的每一个都会导致单个阻塞数据库调用。然后，您的系统需要每秒处理5000个数据库调用。因此，如果您有10个CPU，则每个CPU需要500个线程来处理它们，或者如果您有250个CPU，则每个CPU需要20个线程。但这只是在理想情况下，这些请求实际上并没有阻止和等待。
Play正在使用Akka进行线程管理和并发。优点是在应用程序编程期间不必关心并发的麻烦。
Akka使用available CPUs * parallelism-factor计算最大线程数。此外，您可以使用parallelism-min或parallelism-max限制它们。因此，如果您有250个CPU且parallelism-factor为20，那么您可以同时使用最多5000个线程，这可能会或可能不足以处理您的请求。
回到你的问题：很难说。这取决于数据库调用的时间以及使用CPU进行其他计算的重量。我认为除了尝试并做一些性能测量之外别无他法。但总的来说，由于创建一个线程需要大量资源，所以拥有更少的线程会更好。而且我猜一个20的parallelism-factor对于250个CPU来说是一个很好的起点。
我还向akka-concurrency-test发现了这个文档，它本身有很好的资源列表。