備注：在阿里校招面試中遇到的問題
CPU 限制的應用程序
CPU 限制的應用程序，線程池的大小應該等于系統里面 CPU 的數量。增加更多的線程將中斷請求處理，由于線程上下文切換，這樣也會增加響應時間。
非 I/O 阻塞的應用程序將被 CPU 限制，因為它們沒有線程等待時間，當請求得到處理的時候。
I/O 限制的應用程序
確定 I/O 限制應用程序的線程池的大小是復雜的多，并依賴于下游系統的響應時間，因為一個線程會被阻塞直到其他系統響應了。我們將不得不增加線程的數量,以便更好地利用 CPU，正如在 Reactor Pattern Part 1 : Applications with Blocking I/O 中的討論。
利特爾法則
The long-term average number of customers in a stable system L is equal to the long-term average effective arrival rate, λ, multiplied by the average time a customer spends in the system, W; or expressed algebraically: L = λW.
利特爾法則應用于 Web 應用程序。
在一個系統中的平均線程數量等于平均的 web 請求到達率（每秒的 web 請求數），乘以平均響應時間（ResponseTime）。
QPS:對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力
線程 = 線程數
每秒 web 請求數 = 在 1s 內能被處理的 web 請求數
響應時間 = 處理一個 web 請求所花費的時間
線程 = (每秒 web 請求數) X 響應時間
當以上的方程式提供了需要的線程數來處理傳入的請求，它沒有提供線程 CPU 利用率的信息。比如，多少個線程應該被分配在給定系統的 X CPU。
測試確定線程池大小
為了找出吞吐量和響應時間之間最佳平衡的線程池大小。每個 CPU 最小線程啟動開始（Threads Pool Size = No of CPUs），應用程序線程池大小直接與下游系統的平均響應時間成正比，直到 CPU 使用率爆了，或是響應時間降級。
下面的圖說明了多少個請求數，CPU 和連接響應時間指標。
CPU Vs 請求數圖表顯示了增加 Web 應用程序負載的時候，CPU 的利用率。
響應時間 Vs 請求數圖表顯示了由于增加 Web 應用程序的負載，對響應時間的影響。
綠點表示最佳吞吐量和響應時間。
線程池大小 = CPU 數量
以上圖表描述了阻塞 I/O 限制應用程序，當線程數等于 CPU 數時。應用程序線程被阻塞等待下游系統響應。因為線程被阻塞，響應時間隨著請求進入隊列增加。即使 CPU 利用率非常低，隨著所有的請求被阻塞，應用程序開始拒絕請求。
大線程池
最佳線程池大小
以上圖表描述了當最佳線程池大小在 Web 應用程序中被創建的時，阻塞 I/O 限制了應用程序。CPU 得到有效使用，并由良好的吞吐量和更少的線程上下文切換。我們注意到響應時間是適合由于請求被高效率的處理（很少的中斷）。
線程池隔離
在大部分 Web 應用程序中，一些類型的 web 請求相對于其他類型的 web 請求需要更長的時間來處理。最慢的請求將夯住所有的請求，并降低整個應用程序的性能。
兩種方法來處理這個問題：
有單獨的系統來處理緩慢的Web請求
在同一應用程序中分配給慢的 web 請求一個單獨的線程池
確定一個阻塞 I/O Web 應用程序的最佳線程池大小是一個非常困難的任務。通常通過進行一些性能運行完成。有幾個線程池在 Web 應用程序中會更加復雜化確定最佳線程池大小的過程。
