最近做
portal
的壓力測試，一個字“累”。其中犯了不少錯誤，白白加了幾天班，也有一些體會，就記錄下來，希望對大家有所幫助。
首先講壓力測試環境。這個很是關鍵，我們就是在這個上面吃了苦頭。我們用的
loadrunner
，原理也很簡單，一臺主控機，控制多臺客戶機，模擬并發用戶訪問應用。然后需要能實時監控各相關應用服務器，
ldap
服務器等的性能。這里每臺客戶機最好能使用同樣的配置，使用足夠帶寬的網絡，給予同樣的負載（模擬同樣數量的用戶）。同時要注意監控客戶機的
cpu
和網絡狀況，時刻保證
cpu
和網絡利用率低于
100%
。我們犯的很大錯誤就是使用各自的筆記本，而且都使用的是一個
10M hub
牽出的網線，這樣導致實際的網絡阻塞，既沒有給予服務器足夠的負載，又導致報告的響應時間比實際更長，從而帶來了后續很多的無用測試。
然后講測試方法。用的較多的還是持續壓力測試，就是持續給予服務器一段時間的并發量（一般為
5
到
10
分鐘），然后看平均響應時間是否在可以接受的范圍內。這個“可接受”要視應用類型和實際的并發用戶而定，如何估計并發就要靠經驗了。對于
portal
而言，由于要與眾多的應用接口，如進行
SSO
，獲取數據等，有很大程度也依賴于其它應用的性能，其性能要求不會太高。我們測試首頁的性能，在放上全部的
portlet
的情況下，
100
個并發的平均響應時間就在
17s
左右，這肯定是不能接受的（
10s
只能算勉強可以）。接下來就是發現性能瓶頸，并嘗試進行優化了。
初步的發現瓶頸的方法也很簡單，通過對
portlet
的增減，發現最影響性能的
portlet
，然后不斷優化，直至達到可以接受范圍。發現瓶頸所在了，就得進一步確定是什么原因：是我們本身程序的問題，還是其它應用接口性能不佳等等。這里光靠猜是不行的，要講數據講事實，記錄時間日志就是簡單有效的辦法，我們對各個時間點打印了日志，比如
doview
方法的全部執行時間，
jsp
的載入時間，具體接口的執行時間等。有些接口可能在壓力較小的情況下性能不錯，而在大壓力情況下出現性能隱患，所以一定要在進行壓力測試后查看日志。我們就是這樣發現了性能隱患，同時更進一步對各方面進行優化，直至達到客戶可以接受為止。
由于不是專門的測試人員，很多地方都是實際項目中的體會，也沒什么理論基礎。有什么不對的地方，大家多交流。