播放2框架如何測量線程每秒

Question

這是我的第一篇文章，我是數據庫管理員，並期待使用播放框架版本2.4。我已經閱讀了劇本2的文檔，並且還有幾個問題，因爲我對它很陌生。我有一個消息系統需要處理每秒高達50,000個阻塞線程的負載。如果我是正確的發揮可用線程的最大數量如下：

並行性因子* AvailableProcessors

凡並行性因子是可以每個內核使用的線程數量？我已經看到大多數例子的這個數字是1.0，那麼大約100多有什麼問題？我現在將P-Factor設置爲10.0，並且我擁有150個CPU核心，這意味着我有最多1,500個線程可用（如果是這種情況），並且我必須每秒處理多達50,000個阻塞請求，那麼系統會很慢嗎？，所以唯一的擴展方法是添加更多的核心，因爲所有的請求都被阻塞了？

Answer 1

'每秒50,000次阻塞請求'並不一定意味着你需要50.000個線程來處理它們。每個數據庫調用都不需要線程。

做一個非常簡單的計算：每個數據庫調用需要0.1秒，這是一個任意數字，因爲我不知道你的調用需要多長時間。並且每個50.000請求都會導致一個阻塞的數據庫調用。然後你的系統需要每秒處理5000次數據庫調用。所以如果你有10個CPU，你需要每個CPU 500個線程來處理它們，或者如果你有250個CPU，你需要每個CPU 20個線程。但這只是在理想情況下，這些請求實際上並沒有做任何其他的事情，而不是阻止和等待。

由於其線程管理和併發性，使用Akka。好處是，您不必再在應用程序編程期間關心併發的麻煩。

Akka用available CPUs * parallelism-factor計算最大線程數。此外，您可以使用parallelism-min或parallelism-max來限制它們。所以如果你有250個CPU，而你的parallelism-factor是20，那麼你最多有5000個線程可用，這可能或可能不足以處理你的請求。

所以回到你的問題：這很難說。這取決於數據庫調用的時間以及您將CPU用於其他計算的重量。我認爲除了嘗試並做一些性能測試之外別無他法。但總的來說，線程數量較少會更好，因爲創建線程需要大量資源。我猜想在你的情況下，對於250個CPU來說，20的parallelism-factor是一個很好的起點。

我也發現這個文檔到akka-concurrency-test，它本身有一個很好的來源列表。

Answer 2

Play是爲異步編程創建的。這就是並行因子爲1.0的原因。當你做很多小而快的非阻塞算法時，這是最優的。

問題是你是什麼意思「每秒50,000個線程阻塞」。阻塞可能不同。阻塞的最普遍的例子是訪問RDBMS。我敢肯定，在這種情況下，你的系統可以像處理一個魅力一樣處理50000阻止數據庫訪問。

Play Thread Pool文檔中的示例說，對於使用阻塞數據庫調用的應用程序來說，將並行度因子設置爲300是很好的，因此150 * 300 = 45 000 - 幾乎是您的數量。