網店版重生項目中，因爲我們要將最主要的核心數據由Oracle遷移到分佈式Mysql中；雖然說業務邏輯不進行任何改動，只是將數據源由單一的Oracle改造成基於Mysql的動態數據源，但爲了保險起見，我們還是要求做一次性能測試，但怎麼圧呢？這個系統已經2年沒有比較大的系統變動了，但是用以前的性能測試結果來和新系統做對比，大家都覺得不那麼匹配，所以我們決定：對現有的老系統的關鍵模塊重新進行一次壓力測試，然後和新系統相同模塊的壓力測試結果進行對比，看新系統是否有明顯的性能下降！
但對老系統進行壓力測試的結果卻令我們大失所望，遠遠超出了我們的想象，一些並不複雜的功能點都只有不到20的TPS！這下可把我們嚇壞了，依據我們原有的性能測試數據，類似的功能模塊一般都能達到100TPS左右，難道系統真的年老失修已經變成了現在這麼慢的地步？我們自己當然不相信，因爲系統並沒有進行過大的架構調整，於是開始了路漫漫的排查過程；
性能測試過程中反映出來的現象爲：不管多少併發用戶訪問、系統的TPS都只能保持在十幾，但是Web服務器、DB的壓力卻很低，增加併發數也沒有用，而且每個請求的響應時間並沒有下降，整個應用的TPS曲線非常穩定，長時間壓力、增加併發用戶等也都沒有下降的趨勢！
- 首先，因爲Web應用服務器和DB的load都很低，而且新增併發用戶壓力也都沒有增加的跡象；
所以我們懷疑是否壓力真正到了Web服務器上，是不是壓力測試腳本有問題，於是我們利用現有測試腳本，只是隨便換了一個只通過apache訪問的靜態資源，壓過之後發現沒有問題，TPS立馬上去了，能夠達到幾千； - 在確認了apache沒有問題之後，我們懷疑是否apache、jboss之間的橋接出了問題？
我們默認採用的是weblogic的apache轉接module，檢查相關配置項之後也沒有發現任何問題，只是開啓了一些日誌項，有時候日誌打印也會導致性能瓶頸，關閉之後再圧，仍然沒有起色；
我們也考慮過換一個橋接器，比如用mod_jk，但由於我們幾乎所有系統都是採用現在weblogic的module，且都沒有問題，所以我們決定暫時不做這個調整測試； - 爲了徹底驗證是否因爲apache、jboss之間的橋接出現了瓶頸，我們乾脆把apache去掉了，直接訪問jboss；
再次壓力的測試結果仍然是一樣的，沒有任何變化； - 從我們通過Interceptor打印出來的服務端頁面所消耗的時間來看，頁面的響應速度和我們預期是差不多的，而且增加併發用戶並沒有導致響應時間下降，所以我們還是要想方設法來解決掉這個問題，至少要讓web服務器的壓力上去、或者讓頁面的響應時間下降！
此時我們換了一個更簡單的、沒有數據庫訪問的Jsp頁面進行壓力測試，測試結果令我們出乎意料，TPS很快能夠達到好幾百； - 在對純粹jsp頁面測試的結果之上，我們懷疑是否是因爲各類Interceptor、Filter所消耗的時間太長或者出現瓶頸，因爲通過我們的interceptor打印出來的消耗時間是不包括很多攔截器的；
於是將很多的攔截器去掉之後再圧，結果卻還是和前面一樣，TPS無法獲得提升； - 此時我們懷疑是否因爲Tomcat默認配置的250個線程數太少？但這明顯說不通，因爲我們的測試腳本按理論計算都沒法達到每秒250的請求量；但我們還是通過jmx-console中的stat查看了當前jboss接收的請求數情況；
從console stat的結果來看，感覺還是有些不對，因爲偶爾真的會出現阻塞，250個線程並用完了，還有一些正在等待，這和我們理論計算的結果是相沖突的，於是問題還是迴歸到了應用本身，應用的確有問題； - 前面我們一直堅信，應用是沒有問題的，應該是測試環境、或者壓力腳本、或者其他什麼導致了這個性能瓶頸；也就沒有真正從應用這個角度來分析；
關鍵時刻，看來還得要用終極命令kill -3來查看jboss當前情況下dump出來的堆棧信息了，馬上行動，果然有發現！先看看我們dump出來的一些關鍵信息：
從上面看出，很多的線程都被lock住了，而且都是在ConfigurationManager.conditionalReload；
Wow，一下子恍然大悟嘍，這是webwork的一個配置項導致的結果，就是在開發階段爲了方便，系統會每次都去檢測xwork.xml文件是否有修改過，如果有修改過就重新加載，這個配置項就是webwork.configuration.xml.reload=true；
將配置項設置爲false之後再圧，果然問題就出在這兒，一切正常，TPS恢復到90多，問題搞定！
從這次的性能測試瓶頸問題解決歷程可以看出，環境配置有多麼的重要，往往一個debug級別的參數設置會讓整個應用的性能下降好幾倍！另外，就是對命令kill -3的使用，一般還可以結合jstack一起使用，但一般來說前者dump出來的信息會更全一些，但該命令也不一定使用一次就能發現應用的所有問題，有時候可能需要多次使用，然後一起分析dump日誌；
