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