一、背景
最近負責做一個平臺的poc測試，性能測試要求測試1000併發下平臺的表現，web服務器採用的是weblogic，版本是11g，10.3.6，所有操作都是基於這個版本（因爲以前修改線程數的操作有些基於這個版本不能生效）。在LoadRunner壓1000併發下，發現應用表現並不好，響應時間明顯增加。
二、分析
監控服務器資源，發現集羣平臺服務器負載並不高，而web應用服務器負載同樣也不高，服務器性能並沒達到瓶頸。進入weblogic控制檯，查看線程池，發現在壓1000併發的時候，請求積壓隊列明顯較多，而線程數只有50左右。說明一下，weblogic產品模式下，默認初始線程數爲25，開發模式下好像是15，weblogic11g採用的是自調整線程池，看名字就可以猜出，他會根據應用情況自動增加減少線程數，而實際情況下，在壓力增大的情況下，weblogic也確實增加了線程數，但是增加的線程數不足以應付該需求，於是自然而然地想到了增加線程數。
三、解決
weblogic11g已經不支持在控制檯修改線程數，只能通過配置文件，網上有朋友說可以通過增加weblogic啓動參數來配置線程數:
-Dweblogic.threadpool.MinPoolSize=100
-Dweblogic.threadpool.MaxPoolSize=500
該方法經試驗，並不能生效，還好還一種方法，修改域下面conf裏面的config.xml文件：
<server>
<name>AdminServer</name>
<self-tuning-thread-pool-size-min>400</self-tuning-thread-pool-size-min>
<self-tuning-thread-pool-size-max>400</self-tuning-thread-pool-size-max>
<listen-address/>
</server>
在這裏把線程數最大值最小值都設成了400，400這個數值不是亂設的，WebLogic可以近乎線性地提高線程數。線程數越多，花費在線程切換的時間也就越多；線程數越小，CPU可能無法得到充分的利用。爲獲取一個理想的線程數，需要經過反覆的測試。一般來說一個CPU最好小於50個線程數（注：筆者剛纔發現之前我把CPU數當成了核心數，筆者用的服務器是24核，所以當時理所當然認爲設置1000個線程數也是ok的）。最開始使用1000線程數做測試，因爲最大併發數是1000，筆者想象來一個請求就給一個線程處理，沒有請求排隊，實際上確實如此，但是把線程數調低後，發現即使有排隊情況出現，但響應時間卻比之前1000線程要快，爲什麼會出現這種情況呢？原來還有一點我們忘記了，數據庫連接池。數據庫連接池也是影響性能的指標之一，想想應用1000個請求過來，但是數據庫連接數不夠，在數據庫這邊排隊，還是會影響整體性能表現，所以如何配置weblogic線程數以及數據庫連接線程數使整體性能達到最優，這需要再仔細測試，如果數據庫連接數也能設置到1000，我想應該這是一個比較理想的設置，但很多情況下根據平臺不同，不可能這麼簡單，過高的連接數總會佔用過多系統資源，引發GC等一系列問題。筆者的應用根據多次測試，把數據庫連接跟線程數設置成了一樣的，都是400，這肯定不是最優的，但應該算是性能表現比較滿意的一組值。
四、總結
1、出現性能瓶頸時，先找出現瓶頸的地方，是應用服務器還是數據庫服務器
2、判斷是否需要修改weblogic線程數以及數據庫連接池的值
3、多次測試，得出一組合適的weblogic線程數的值以及數據庫連接數的值