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