某某門戶網站性能測試報告

WORD格式整理專業(yè)資料值得擁有XXX門戶網站性能測試報告

目錄第一章 概述 4第二章 測試活動 42.1測試用具 42.2測試范圍 42.3測試目標 52.4測試方法 52.4.1基準測試 52.4.2并發(fā)測試 62.4.3穩(wěn)定性測試 62.5性能指標 62.6性能測試流程 6第三章 性能測試環(huán)境 73.1服務器環(huán)境 73.2客戶端環(huán)境 83.3網絡結構 9第四章 測試方案 94.1基準測試 94.2并發(fā)測試 114.3穩(wěn)定性測試 13第五章 測試結果描述 145.1性能測試觀察指標 145.2性能測試通過指標 15用戶體驗性能 155.3測試結果 15第六章 測試報告系統(tǒng)測試公范圍：基準測試階段，并發(fā)測試階段，穩(wěn)定性測試，浪涌式測試。 156.1基準測試性能分析 166.2并發(fā)測試性能分析 216.3穩(wěn)定性性能測試分析 24

摘要本文檔主要描述XXXX門戶網站檢索和頁面瀏覽性能測試中的測試內容、測試方法、測試策略等。修改歷史日期版本作者修改內容評審號更改請求號2016-01-141.0測試組新建。性能測試2016-01-141.0測試組修改性能測試回歸2016-01-141.0測試組更新注釋：評審號為評審記錄表的編號。更改請求號為文檔更改控制工具自動生成的編號。

概述由于當前對系統(tǒng)要接受業(yè)務量的沖擊，面臨的系統(tǒng)穩(wěn)定、成熟性方面的壓力。系統(tǒng)的性能問題必將成為焦點問題，海量數據量的“沖擊”，系統(tǒng)能穩(wěn)定在什么樣的性能水平，面臨業(yè)務增加時，系統(tǒng)抗壓如何等這些問題需要通過一個較為真實的性能模擬測試來給出答案，通過測試和分析為系統(tǒng)性能的提升提供一些重要參考數據，以供后期系統(tǒng)在軟硬件方面的改善和完善。本《性能測試報告》即是基于上述考慮，參考當前的一些性能測試方法而編寫的，用以指導即將進行的該系統(tǒng)性能測試。測試活動2.1測試用具本次性能測試主要采用HP公司的Loadrunner11作為性能測試工具。Loadrunner主要提供了3個性能測試組件：VirtualUserGenerator,Controller,Analysis。使用VirtualUserGenerator修改和優(yōu)化腳本。使用Controller進行管理，控制并發(fā)的模擬并發(fā)數，記錄測試結果。使用Analysis進行統(tǒng)計和分析結果。2.2測試范圍此次性能測試實施是對xxxxxx門戶網站系統(tǒng)性能進行測試評估的過程，我們將依據系統(tǒng)將來的實際運行現狀，結合系統(tǒng)的設計目標和業(yè)務特點，遵循著發(fā)生頻率高、對系統(tǒng)或數據庫性能影響大、關鍵和核心業(yè)務等原則選取需要進行測試的業(yè)務，模擬最終用戶的操作行為，構建一個與生產環(huán)境相近的壓力場景，對系統(tǒng)實施壓力測試，以此評判系統(tǒng)的實際性能表現。根據與相關設計，開發(fā)人員的溝通和交流，本次測試主要就是針對大量用戶在使用XXX門戶網站進行信息查詢，而選取的典型事務就是用戶使用檢索進行關鍵字搜索以及界面瀏覽和反饋回搜索結果，這是用戶使用最頻繁，反應最多的地方，也是本系統(tǒng)當前以及以后業(yè)務的一個重要壓力點所在。所以本次測試只選取檢索業(yè)務的性能情況和界面瀏覽進行記錄和分析。2.3測試目標本次測試是針對XXXX網站檢索和頁面瀏覽在迎接大業(yè)務量的壓力下而進行的，主要需要獲得如下的測試指標。1、系統(tǒng)的穩(wěn)定負載能力：即在正常的響應時間中，系統(tǒng)能夠支持的最多的客戶端的數量，例如：找到用戶可容忍的基本響應時間為5秒時，系統(tǒng)的支持用戶數。2、系統(tǒng)的極限負載能力：即在某個較長的響應時間，客戶主觀上已無法容忍的情況下，系統(tǒng)能夠支持的最多的客戶端的數量。3、系統(tǒng)的無故障運行時間：即在得出系統(tǒng)的最合理的響應時間和支持響應的客戶端數量該前提下，無故障運行時間，暫定8--12小時。2.4測試方法 總體方法：使用美科利公司（Mercury）的性能測試軟件LoadRunner，對現行的系統(tǒng)檢索，頁面預覽進行腳本錄制、測試回放、逐步加壓和跟蹤記錄。測試過程中，由LoadRunner的管理平臺調用各臺測試前臺，發(fā)起檢索查詢請求，并跟蹤記錄服務器端的運行情況和返回給客戶端的運行結果。 此次性能測試在http://www.xxxxxx進行，環(huán)境在服務器軟件、硬件上與生產環(huán)境保持一致，數據庫結構和真實環(huán)境數據庫結構一致，只是在網絡帶寬上有一定的區(qū)別，實際外網帶寬會有所不足。本次將進行基準測試，并發(fā)數測試，穩(wěn)定性測試3種類型測試，并對主要測試指標進行記錄和分析。2.4.1基準測試基準測試在系統(tǒng)無壓力（外界環(huán)境，服務器無額外服務運行，無額外監(jiān)控進程運行）的情況下，取得各項事務和業(yè)務的系統(tǒng)并發(fā)用戶數和平均響應時間作為分析衡量標準，用于初步診斷系統(tǒng)是否存在性能瓶頸。2.4.2并發(fā)測試沒有明確的系統(tǒng)性能指標前提下，用Loadrunner模擬多用戶同時向服務器發(fā)起交易請求，運行過程中每個用戶沒有思考時間（ThinkTime）的情況下持續(xù)提交交易請求，向系統(tǒng)施加壓力。2.4.3穩(wěn)定性測試重點測試支付系統(tǒng)在業(yè)務高峰期壓力下運行的穩(wěn)定性。2.5性能指標在本次性能測試，由于沒有具體和明確的性能指標，所以各類測試指標包括測試中應該達到的某些性能指標和相關服務器的性能指標，都應該受到以下三個基本條件的約束。業(yè)務執(zhí)行的平均響應時間（期望值：<=5s）CPU利用率小于75%內存Pagingrate狀態(tài)未持續(xù)處于高位運行2.6性能測試流程通過自動化測試工具模擬最終用戶向服務器發(fā)起業(yè)務請求，進行性能測試。通過測試工具對測試過程中系統(tǒng)各點進行監(jiān)控，每一次測試結束后工具自動生成結果報告供分析使用。2.7測試術語系統(tǒng)的響應時間：即在各種負載壓力情況下，系統(tǒng)的響應時間，也就是從客戶端交易發(fā)起，到服務器端交易應答返回所需要的時間，包括網絡傳輸時間和服務器處理時間。應用系統(tǒng)的吞吐量：即應用系統(tǒng)在單位時間內完成的交易量，也就是在單位時間內，應用系統(tǒng)針對不同的負載壓力，所能完成的交易數量。應用系統(tǒng)的負載能力：即系統(tǒng)所能容忍的最大用戶數量，也就是在正常的響應時間中，系統(tǒng)能夠支持的最多的客戶端的數量?？s略語：Vuser，Transaction，TPSVuser虛擬用戶Virtualuser,模擬真實業(yè)務邏輯步驟的虛擬用戶,虛擬用戶模擬的操作步驟都被記錄在虛擬用戶腳本里。Vuser腳本用于描述Vuser在場景中執(zhí)行的操作。Transaction事務事務是性能測試腳本的一個重要特性。要度量服務器的性能,需要定義事務,每個事務都包含事務開始和事務結束標記。事務用來衡量腳本中一行代碼或多行代碼的執(zhí)行所耗費的時間.可以將事務開始放置在腳本中某行或者多行代碼的前面,將事務結束放置在該行或者多行代碼的后面,在該腳本的虛擬用戶運行時,這個事務將衡量該行或者多行代碼的執(zhí)行花費了多長時間。TPS每秒事務數(TransactionPerSecond)每秒鐘系統(tǒng)能夠處理的交易或事務的數量,它是衡量系統(tǒng)處理能力的重要指標。TPS是LoadRunner中重要的性能參數指標。性能測試環(huán)境3.1服務器環(huán)境數據庫服務器：服務器型號：IBMCPU：8核Intel(R)Xeon(R)CPUE5-2650v2@2.60GHz內存：32GB系統(tǒng)盤：云磁盤數據盤：云磁盤操作系統(tǒng)：應用軟件：3.2客戶端環(huán)境資源描述數量Loadrunner11主要性能測試工具1Office2007用于記錄測試數據2WindowsXPSP3,Windows7測試客戶端系統(tǒng)1IE10，Firefox及其組件測試客戶端應用軟件1PC測試計算機23.3網絡結構網絡拓撲和結構圖如下：測試方案本次性能測試主要模擬測試的事務：用戶信息瀏覽檢索用戶提交查詢關鍵字數據到后臺，系統(tǒng)收到查詢請求并檢索、返回結果數據；性能測試觀察指標：Bs結構程序一般會關注的通用指標如下：Web服務器指標指標：*AvgRps:平均每秒鐘響應次數=總請求時間/秒數；*SuccessfulRounds：成功的請求；*FailedRounds：失敗的請求；*SuccessfulHits：成功的點擊次數；*FailedHits：失敗的點擊次數；*HitsPerSecond：每秒點擊次數；*SuccessfulHitsPerSecond：每秒成功的點擊次數；*FailedHitsPerSecond：每秒失敗的點擊次數；*AttemptedConnections：嘗試鏈接數；執(zhí)行每個場景時記錄以下相應的數據：業(yè)務執(zhí)行的平均響應時間每秒事務數運行的并發(fā)用戶數目網絡吞吐量4.1基準測試場景：（歷史數據有1000條以上）使用Loadrunner模擬50用戶請求交易，每個用戶沒有時間間隔（ThinkTime）的情況下反復提交交易并返回結果，直到全部執(zhí)行退出系統(tǒng)。記錄平均事務響應時間，每秒事務數，吞吐量。記并發(fā)數改為100，同時加壓，同時結束壓力，重復上述測試步驟。并發(fā)數改為200，重復上述測試步驟。當響應時間大于期望時間，或者服務器指標超過預訂設置時將停止測試。備注：以上測試均進行3次，來保證測試結果的有效性和準確性。4.2并發(fā)測試場景：（歷史數據有1000條以上）使用Loadrunner模擬50用戶請求交易，每個用戶沒有時間間隔（ThinkTime）的情況下反復提交交易并返回結果，持續(xù)時間分別為10分鐘，15分鐘，20分鐘，記錄平均事務響應時間，每秒事務數，吞吐量。記并發(fā)數改為100重復上述測試步驟。并發(fā)數改為200，重復上述測試步驟。當響應時間大于期望時間，或者服務器指標超過預期設置時將停止測試。備注：以上測試均進行3次，來保證測試結果的有效性和準確性。3次執(zhí)行時間分別為10分鐘，15分鐘，20分鐘。4.3穩(wěn)定性測試測試方法：采用業(yè)務中合理、適度的用戶使用場景，對系統(tǒng)進行時間為8--12小時的穩(wěn)定性測試。記錄每次服務的平均響應時間，交易的正確率，考察服務器是否宕機，交易正確率小于95%等情況。穩(wěn)定性測試的用例如下：場景：（歷史數據有1000條以上）使用Loadrunner模擬200個并發(fā)用戶請求交易，每個用戶有一定時間間隔（ThinkTime）1秒的情況下反復點擊頁面和信息檢索并返回結果，持續(xù)執(zhí)行8--12小時（2016-1-14-20:302016-1-15-8:30）共計69688）每秒5次以上的點擊和檢索，記錄平均事務響應時間，每秒事務數，吞吐量。觀察軟件的穩(wěn)定性以及各種性能指標的劣化趨勢，要有效防止資源泄露。當服務器出現資源泄露或者系統(tǒng)的資源耗盡等情況，交易正確率小于95%，停止測試。第五章測試結果描述和分析6.1基準測試性能分析 設計50、100、200個用戶并發(fā)，沒有持續(xù)加壓時間，直至執(zhí)行完成。獲取系統(tǒng)的各種表現。50個用戶的測試信息統(tǒng)計：100個用戶的測試信息統(tǒng)計：200個用戶的測試信息統(tǒng)計：事務平均響應時間序號單項事務用戶數響應時間（s）備注50100200總流程時間5.6435.7778.59450個用戶的響應時間：100個用戶的響應時間：200個用戶的響應時間：從以上圖中可以看出，服務器在50，100個并發(fā)的情況下所有事務都保持在5s左右，但稍微高于5s，應該有一定的上升空間。最大的問題在于并發(fā)數200后，處理時間已經在5s以上，達到8s。建議：優(yōu)化請求響應模塊以及檢索應用模塊，減少響應時間。TPS（事務數/秒）50個用戶的每秒事務數：100個用戶的每秒事務數：200個用戶的每秒事務數：從以上每個圖中看到TPS達到峰值1后開始有下降的趨勢，基本上均在1個事物以下，這個數據并不理想，我們服務器的性能還沒有充分發(fā)揮，現有硬件條件下還可以在單位時間內處理更多的事務數，建議在下一階段進行優(yōu)化提升?；蛘呤蔷W絡不佳的情況導致該情況的出現。吞吐量并發(fā)數TotalThroughput(bytes)AverageThroughput(bytes/second)50128,707,404347,858100257,386,009993,768200514,838,2262,394,59650個用戶的吞吐量：100個用戶的吞吐量：200個用戶的吞吐量：從圖中可以看出總吞吐量隨著用戶的增加成正比的，數據交換正常。但是，在對網絡帶寬，系統(tǒng)架構，硬件資源的合理分配后應該能發(fā)揮系統(tǒng)的更大處理能力。6.2并發(fā)測試性能分析設計50、100、200個用戶并發(fā)，分別持續(xù)10分鐘，15分鐘，20分鐘，獲取系統(tǒng)的各種表現。50個用戶并發(fā)的測試統(tǒng)計信息（以10分鐘為例）：100個用戶并發(fā)的測試統(tǒng)計信息（以10分鐘為例）：200個用戶并發(fā)的測試統(tǒng)計信息（以10分鐘為例）：平均事務響應時間測試用例響應時間(單位：秒)并發(fā)50持續(xù)5分鐘14.009并發(fā)50持續(xù)10分鐘15.31并發(fā)50持續(xù)15分鐘11.178并發(fā)100持續(xù)5分鐘16.318并發(fā)100持續(xù)10分鐘14.143并發(fā)100持續(xù)15分鐘15.675并發(fā)200持續(xù)5分鐘24.859并發(fā)200持續(xù)10分鐘24.997并發(fā)200持續(xù)15分鐘26.34950個并發(fā)（以10分鐘為例）：100個并發(fā)（以10分鐘為例）：200個并發(fā)（以10分鐘為例）：從圖中看出，并發(fā)用戶數同時進行5分鐘，響應時間就已經在10s以上了，隨著并發(fā)用戶數和持續(xù)時間的增加，響應時間變得越來越長，當200個并發(fā)的時候已經超過20秒，已經相對較慢，但是這只是實驗室理論測試數據，在實際生產環(huán)境中過高的并發(fā)數和過長的持續(xù)壓力時間這種極端情況很少。但是并發(fā)持續(xù)了5分鐘這種情況下，我們的響應時間還是應該可以控制在5秒以內，使我們系統(tǒng)在較大的業(yè)務量的情況下可以提供較為滿意的用戶體驗。導致這樣的一種情況主要來自于網絡不佳造成（該問題并不是由于服務器端的網絡不良，而是來自用戶端的網絡不佳導致）TPS（事務數/秒）（以10分鐘為例）測試用例TPS并發(fā)50持續(xù)10分鐘3.086并發(fā)100持續(xù)10分鐘6.260并發(fā)200持續(xù)10分鐘7.18450個并發(fā)（以10分鐘為例）：100個并發(fā)（以10分鐘為例）：200個并發(fā)（以10分鐘為例）：TPS數值并不理想，它反映了服務器處理能力一般，沒有充分發(fā)揮應用服務器的事務處理能力。建議：在下一個階段需要優(yōu)化。但是這個原因可能是由于網絡帶寬、前置接入系統(tǒng)處理能力較小，比如：連接數有所限制，所以最后到達核心應用服務器事務數較小，連鎖導致最終事務處理能力上不去。吞吐量（以10分鐘為例）測試