原文地址：http://blog.sina.com.cn/s/blog_4080505a01016o3d.html

最佳線程數:

性能壓測的情況下，起初隨著用戶數的增加，QPS會上升，當到了一定的閥值之後，用戶數量增加QPS並不會增加，或者增加不明顯，同時請求的響應時間卻大幅增加。這個閥值我們認為是最佳線程數。

為什麽要找最佳線程數

1.過多的線程只會造成，更多的內存開銷，更多的CPU開銷，但是對提升QPS確毫無幫助

2.找到最佳線程數後通過簡單的設置，可以讓web系統更加穩定，得到最高，最穩定的QPS輸出

最佳線程數的獲取：

1、通過用戶慢慢遞增來進行性能壓測，觀察QPS，響應時間

2、根據公式計算:服務器端最佳線程數量=((線程等待時間+線程cpu時間)/線程cpu時間) * cpu數量

3、單用戶壓測，查看CPU的消耗，然後直接乘以百分比，再進行壓測，一般這個值的附近應該就是最佳線程數量。

影響最佳線程數的主要因素：

1、IO

2、CPU

根據公式：服務器端最佳線程數量=((線程等待時間+線程cpu時間)/線程cpu時間) * cpu數量

一般來說是IO和CPU。IO開銷較多的應用其CPU線程等待時間會比較長，所以線程數量可以開的多一些，相反則線程數量要少一些，其實有兩種極端，純IO的應用，比如proxy，則線程數量可以開到非常大（實在太大了則需要考慮線程切換的開銷），這種應用基本上後端（比如這個proxy是代理搜索的）的QPS能有多少，proxy就有多少。

另一種是耗CPU的計算，這種情況一般來講只能開到CPU個數的線程數量。但是並不是說這種應用的QPS就不高，往往這種應用的QPS可以很高。

QPS和線程數的關系

1、在最佳線程數量之前，QPS和線程是互相遞增的關系，線程數量到了最佳線程之後，QPS持平，不在上升，甚至略有下降，同時相應時間持續上升。

2、同一個系統而言，支持的線程數越多（最佳線程數越多而不是配置的線程數越多），QPS越高

QPS和響應時間的關系

1、對於一般的web系統，響應時間一般有CPU執行時間+IO等待時間組成

2、CPU的執行時間減少，對QPS有實質的提升，IO時間的減少，對QPS提升不明顯。如果要想明顯提升QPS，優化系統的時候要著重優化CPU消耗大戶。

最佳線程數和jvm堆內存得關系：

以上都是依據性能瓶頸在CPU的情況，對於java應用還有一個因素是FULL GC，我們要保證在最佳線程數量下，不會發生頻繁FULL GC

根據公式：：(小GC時間間隔/rt)*(並發線程數量 * thm) <=young 計算得到的並發線程數量如果<最佳線程數量 則可能導致FULL GC較頻繁，實際情況看來這種情況在web系統上非常少。不過可以模擬出來。

所以我們在設置jboss線程的時候，可以利用內存公式計算出來的線程數量來設置，通過壓測和計算得到最佳線程數，然後設置線程數。

設置線程數量：

壓測最佳線程數<真實設置的線程數量<內存極限線程數

比如，通過壓測得到某系統的最佳線程數量是10，然後通過內存計算的線程數量是20，則，設置jboss的線程數量為15是可行的，如果直接設置了10，由於系統本身會受到一些依賴系統的變化而產生一些變化，比如系統依賴一些IO的響應時間會突然延長，由於線程數量還是10，其實這個時候最佳線程數量已經變成了13了，由於我們設置死了10，其結果就是導致qps下降，但是如果超過20，則又會引起FULL gc非常頻繁，反過來影響QPS的下降。

jboss的線程數設置：

對於jboss而言，設置線程數量要看使用了那種線程連接，如http、ajp等

http和ajp的設置是完全一樣的，非常簡單：

以ajp為例，找到server.xml或者tomcat-server.xml:

默認線程數量是200個

<Connector port="8009" address="${jboss.bind.address}" connectionTimeout="15000" protocol="AJP/1.3" maxThreads="200" minSpareThreads="40" maxSpareThreads="75" maxPostSize="512000" acceptCount="300" bufferSize="16384" emptySessionPath="false" enableLookups="false" redirectPort="8443" useBodyEncodingForURI="true"/>

這裏將默認的線程數量改成了20，當然相應的其他最小空閑線程數和最大空閑線程數也做一下調整：

<Connector port="8009" address="${jboss.bind.address}" connectionTimeout="15000" protocol="AJP/1.3" maxThreads="20" minSpareThreads="20" maxSpareThreads="20" maxPostSize="512000" acceptCount="300" bufferSize="16384" emptySessionPath="false" enableLookups="false" redirectPort="8443" useBodyEncodingForURI="true"/>

按照上方理論，jmeter壓測得出實踐到的最佳線程數：

在性能測試方法論中，很典型的方法就是二八原則，量化業務需求。

二八原則：指80%的業務量在20%的時間裏完成。

如何理解，下面我們來個例子吧

用戶登錄場景：早高峰時段，8：50---9：10，5000坐席上線登陸。

業務量：5000個

時間：20x60=1200秒

吞吐量=80%x業務量/(20%*時間)=4000/240=16.7/秒

而並非5000/1200=4.1/秒

實際上，登錄請求數分布是一個正態分布，最高峰時肯定比4.1/秒更高，高峰段實際上完成了80%的業務量，卻只花了20%的時間。

溫馨提示：

1.二八原則計算的結果並非在線並發用戶數，是系統要達到的處理能力（吞吐量），初學者容易被誤導，那這這個數據就去設置並發數，這是錯誤滴。

2.如果你的系統性能要求更高，也可以選擇一九原則或更嚴格的算法，二八原則比較通用，一般系統性能比較接近這個算法而已，大家應該活用。

3.tps、響應時間、在線並發數三者關系詳解：點擊打開鏈接

三者關系圖

2. 結論

• 小並發數區間測試，找拐點（如：100-300並發持續5分鐘，可以發現上圖中200並發時出現拐點）
• 大並發數區間測試，找符合需求的最大並發數（如：1800-2200並發持續5分鐘，可以找到滿足響應時間在3秒內的最大並發數2000）
• 利用最大並發數，壓測環境在極限時的資源消耗（壓測時間1小時以內）
• 80%最大並發數，進行穩定性測試（壓測時間1小時以上）

註：執行機資源消耗必須監控上，保證能提供穩定的並發負載。

註：這裏的響應時間是90%響應時間

tps:

最佳線程數設置