1、XX網站性能測試報告目錄XX網站性能測試報告1測試概要2測試用例設計2測試環(huán)境與配置3測試執(zhí)行與記錄4首頁性能測試 策略一：4測試數(shù)據(jù)收集及分析4調優(yōu)建議：6首頁性能測試 策略二：7測試數(shù)據(jù)收集及分析7測試總結9子系統(tǒng)性能測試 策略一：9測試數(shù)據(jù)收集及分析9子系統(tǒng)性能測試 策略二：11測試數(shù)據(jù)收集及分析11測試總結13測試概要本次測試為性能測試，主要就XXXX網站首頁以及三個子系統(tǒng)：銷售支持系統(tǒng)、銷售員查詢系統(tǒng)和意外險查詢系統(tǒng)施加壓力，以平均事物響應時間為上限，測試系統(tǒng)所能承受的最大用戶數(shù)以及服務器資源占用情況等指標。測試用例設計由于主頁與三個子系統(tǒng)分屬不同的服務器，對主頁施加壓力不會對web

2、服務器以及數(shù)據(jù)庫服務器造成影響，因此此次性能測試主要分為對主頁的壓力測試以及對三個子系統(tǒng)的壓力測試兩大部分。首頁分為七大模塊：關于網站、新聞中心、產品博覽、客戶服務、在線投保、客戶留言和加入我們，分析用戶習慣設計用例分布如下：首頁各模塊壓力配比：三個子系統(tǒng)：銷售支持系統(tǒng)、信息查詢系統(tǒng)、營業(yè)員查詢系統(tǒng)在同一服務器上，混合場景設置配比如下：子系統(tǒng)各模塊壓力配比：測試環(huán)境與配置本次性能測試硬件資源采用將來上線時的服務器，本系統(tǒng)采用B/S架構，用戶通過瀏覽器訪問應用系統(tǒng)。環(huán)境主要包括了數(shù)據(jù)庫服務器、應用服務器和壓力測試機。測試結果只適用在本測試環(huán)境上參考。一：公司網站服務器：角色：應用服務器 IBM刀

3、片 HS22操作系統(tǒng)：Windows 2003處理器：2CPU 內存：12GIP：XX.XX.XXX.XX二：子系統(tǒng)（個險銷售支持系統(tǒng)、信息查詢系統(tǒng)、業(yè)務員查詢系統(tǒng)）應用服務器角色：應用服務器 IBM刀片 HS22操作系統(tǒng)：Red Hat Linux處理器：2CPU 內存：12GIP：XX.XX.XXX.XX三：子系統(tǒng)（個險銷售支持系統(tǒng)、信息查詢系統(tǒng)、業(yè)務員查詢系統(tǒng)）數(shù)據(jù)庫服務器角色：數(shù)據(jù)庫服務器 IBM刀片 HS22操作系統(tǒng)：Red Hat Linux處理器：2CPU 內存：12GIP：XX.XX.XXX.XX四：測試服務器角色：測試服務器 DELL PC操作系統(tǒng)：WINXP處理器：2CPU

4、內存：1GIP：XX.XX.XXX.XX IP：XX.XX.XXX.XX 測試執(zhí)行與記錄首頁性能測試 策略一：場景設計：本次測試場景設置根據(jù)被測功能點及各功能點的業(yè)務分配比例，思考時間將采取錄制時間50%150%隨機選取，虛擬用戶模擬IE7瀏覽器訪問首頁。為增大對服務器的壓力，虛擬用戶執(zhí)行下次循環(huán)時作為一個新用戶處理，清除上次運行時的緩存；同時重新下載非HTML資源。壓力策略：主要采取模擬混合場景策略，根據(jù)實際業(yè)務比例分配測試腳本比例，以100為粒度采取逐步加壓策略，目標并發(fā)用戶數(shù)3000個，達到目標用戶數(shù)后再持續(xù)執(zhí)行半個小時左右后停止全部并發(fā)。測試數(shù)據(jù)收集及分析首頁測試結果概要：整個場景執(zhí)行

5、4小時21分42秒，最大并發(fā)用戶數(shù)為2900個，總通過事務數(shù)為1679844個，失敗事務數(shù)0個平均事物相應時間曲線圖：帶寬用戶圖服務器資源圖：從平均事務響應時間曲線來看，隨著并發(fā)壓力的增大，吞吐量也明顯增大，各事務響應時間有明顯的上升趨勢，打開首頁事物上升尤其明顯，在1200并發(fā)用戶數(shù)后，各事務響應時間上升更加迅速，打開首頁事物相應時間超過三秒。此時查看帶寬資源已經到達極限，而服務器資源仍處于平穩(wěn)狀態(tài)，CPU的平均占用率在40%以下，各項指標均在良好運行。上述場景策略運用了最大帶寬以求服務器的負載極限，從場景執(zhí)行情況不難分析出，網絡帶寬占滿后，虛擬用戶的響應時間在等待網絡資源方面開銷較大，從而

6、對服務器的請求率并沒有增加，因此服務器資源一直沒有被占滿。從這個方面看，即使在帶寬滿載的情況下，服務器依然能夠輕松承受所有壓力；但另一方面也表明網絡帶寬已成為系統(tǒng)瓶頸。為此我們單獨運行一個用戶測試，結果為最大占用帶寬200K。將首頁所有圖片下載計算大小，結果亦為200K。在多用戶并發(fā)的情況下，圖片太大直接影響訪問速度。調優(yōu)建議：經測試，首頁圖片過大可能為帶寬占用過高的主要原因，當圖片很多的時候，減少圖片大小是提高下載速度的最直接的方法，建議一些要求不是很高的圖片用PNG8格式的圖片代替JPEG和GIF（非動畫圖片），因為PNG8在效果一樣的情況下圖片大小比后兩個格式要小很多。首頁性能測試 策略

7、二：場景設計：本次測試場景在考慮帶寬限制的情況下充分仿真模擬真實用戶對首頁的訪問，虛擬用戶方面將假設訪問系統(tǒng)主頁的用戶有50%為經常訪問系統(tǒng)的用戶，對于這部分用戶來說，系統(tǒng)為其保存緩存以減少客戶端重復勞動和下載非HTML資源的效率；另外50%為首次訪問系統(tǒng)的新用戶，對于這部分用戶的設置為系統(tǒng)每次循環(huán)都清除緩存，同時重新下載非HTML資源，每組虛擬用戶限制最大吞吐量為1M帶寬。各被測功能點及各功能點的業(yè)務分配比例依照用例設計，思考時間將采取錄制時間50%150%隨機選取，虛擬用戶模擬IE7瀏覽器訪問首頁。壓力策略：主要采取模擬混合場景策略，根據(jù)實際業(yè)務比例分配測試腳本比例，以100為粒度采取逐步

8、加壓策略，目標并發(fā)用戶數(shù)2000個，達到目標用戶數(shù)后再持續(xù)執(zhí)行15min左右后停止全部并發(fā)。測試數(shù)據(jù)收集及分析首頁測試結果概要：整個場景執(zhí)行1小時40分鐘25秒，最大并發(fā)用戶數(shù)為2000，成功事務數(shù)1476162個，失敗事務數(shù)0個平均事務響應時間曲線帶寬用戶圖本次場景設置對每組用戶的帶寬有最大限制，因此系統(tǒng)在逐步加載虛擬用戶的同時會逐步放開帶寬，從平均事務響應曲線來看，由于有50%的用戶模擬虛擬經常訪問系統(tǒng)的老用戶不清除緩存，因此每次剛開始放開加載虛擬用戶時響應時間會有稍許上升，但從總體來看，所有事務響應時間較為平穩(wěn)，且都在3秒以下。測試總結從以上吞吐量明細表來看，隨著并發(fā)壓力的增大，吞吐量也

9、明顯增加，當并發(fā)數(shù)達到2000時，吞吐量達到最大；從第一個場景的執(zhí)行結果來看，在不考慮帶寬的情況下，服務器可在相當于1200個用戶同時訪問的情況下保持良好運轉。 當并發(fā)數(shù)達到500時，吞吐達到3M左右，說明4M帶寬可以支撐同時500人在線使用。 當并發(fā)用戶數(shù)達到700時，吞吐達到4M左右，說明6M帶寬可以支撐同時700人在線使用。同時，應該看到，系統(tǒng)運行一段時間后，隨著經常訪問的老用戶數(shù)的增多，在用戶習慣為保存緩存的情況下，響應時間不會明顯增加。子系統(tǒng)性能測試 策略一：場景設計：本次測試場景設置根據(jù)被測功能點及各功能點的業(yè)務分配比例，思考時間將采取錄制時間50%150%隨機選取，虛擬用戶執(zhí)行下

10、次循環(huán)時作為一個新用戶處理，清除上次運行時的緩存；同時重新下載非HTML資源。壓力策略：主要采取模擬混合場景策略，根據(jù)實際業(yè)務比例分配測試腳本比例，以100為粒度采取逐步加壓策略，目標并發(fā)用戶數(shù)1000個，達到目標用戶數(shù)后再持續(xù)執(zhí)行15min左右后停止全部并發(fā)。測試數(shù)據(jù)收集及分析子系統(tǒng)測試結果概要：整個場景執(zhí)行32分46秒，最大并發(fā)用戶數(shù)為1000個，總通過事務數(shù)為357942個，失敗事務數(shù)2229個平均事務響應時間用戶圖錯誤圖事物統(tǒng)計：從事物平均響應時間來看，前期響應時間一直沒有發(fā)生太大變化，直到從900個并發(fā)用戶增至1000個并發(fā)用戶時，發(fā)生錯誤事務，響應時間也陡然增長。但此時服務器仍處于

11、良好運行狀態(tài)，手動用IE訪問也能打開相應頁面。分析錯誤統(tǒng)計，發(fā)現(xiàn)是負載生成器的TCP/IP端口超時等待所致，由于負載生成器發(fā)數(shù)據(jù)包特別快，服務器也響應特別快，從而導致負載生成器的機器的端口在沒有timeout之前就全部占滿了，從而出現(xiàn)上述錯誤。 解決方法：手工調整TCP的time out。即讓負載生成器在最后一個端口還沒有用到時，前面已經有端口在釋放了。子系統(tǒng)性能測試 策略二：場景設計：測試場景設置根據(jù)被測功能點及各功能點的業(yè)務分配比例，思考時間將采取錄制時間50%150%隨機選取，虛擬用戶執(zhí)行下次循環(huán)時作為一個新用戶處理，清除上次運行時的緩存。同時帶寬限制在每組用戶0.5M 以內壓力策略：根據(jù)上次場景測試發(fā)現(xiàn)，并發(fā)用戶數(shù)在1000以內時的事務平均響應時間平穩(wěn)且能夠達到要求，因此此次場景同時加載并發(fā)用戶數(shù)1000個，達到目標用戶數(shù)后持續(xù)執(zhí)行5min左右后停止全部并發(fā)。測試數(shù)據(jù)收集及分析子系統(tǒng)測試結果概要：整個場景執(zhí)行5分51秒，最大并發(fā)用戶數(shù)為1000個，總通過事務數(shù)為89497個，失敗事務數(shù)0個平均事務響應時間曲線LINUX服務器資源圖帶寬用戶圖從事務平均響應時間曲線來看，各項事務的平均響應時間均比較平穩(wěn)，沒有出現(xiàn)太大波