項目性能測試報告(參考版)
2025-03-29 05:23本頁面
【正文】 但是響應(yīng)時間稍稍有點長了些，可以有進一步調(diào)優(yōu)的空間，一般控制在8s以下為佳（導(dǎo)致響應(yīng)時間較長主要來自于用戶端網(wǎng)絡(luò)不佳的情況導(dǎo)致并非服務(wù)器端的網(wǎng)絡(luò)不佳）。本次測試使用Loadrunner模擬50用戶請求交易，每個用戶沒有時間間隔（ThinkTime）的情況下反復(fù)提交交易并返回結(jié)果，持續(xù)執(zhí)行812小時。 吞吐量（以10分鐘為例）測試用例Total Throughput (bytes)Average Throughput (bytes/second)并發(fā)100持續(xù)10分鐘3,628,897,7475,416,265并發(fā)200持續(xù)10分鐘7,096,275,50910,008,851并發(fā)300持續(xù)10分鐘8,262,379,06911,120,295300個并發(fā)（以10分鐘為例）：500個并發(fā)（以10分鐘為例）：700個并發(fā)（以10分鐘為例）：在運行相同時間的前提條件下，隨著用戶翻倍的增加吞吐量沒有明顯增加。建議：在下一個階段需要優(yōu)化。但是并發(fā)持續(xù)了5分鐘這種情況下，我們的響應(yīng)時間還是應(yīng)該可以控制在8秒以內(nèi)，使我們系統(tǒng)在較大的業(yè)務(wù)量的情況下可以提供較為滿意的用戶體驗。 設(shè)計300、500、700個用戶并發(fā)，分別持續(xù)10分鐘，20分鐘，30分鐘，40分鐘獲取系統(tǒng)的各種表現(xiàn)。 吞吐量并發(fā)數(shù)Total Throughput (bytes)Average Throughput(bytes/second)100 200100個用戶的吞吐量：200個用戶的吞吐量： 從圖中可以看出總吞吐量隨著用戶的增加成正比的，數(shù)據(jù)交換正常。 TPS （事務(wù)數(shù)/秒）100個用戶的每秒事務(wù)數(shù)：200個用戶的每秒事務(wù)數(shù)：從以上每個圖中看到TPS達到峰值1后開始有下降的趨勢，基本上均在1個事物以下，這個數(shù)據(jù)并不理想，我們服務(wù)器的性能還沒有充分發(fā)揮，現(xiàn)有硬件條件下還可以在單位時間內(nèi)處理更多的事務(wù)數(shù)，建議在下一階段進行優(yōu)化提升。最大的問題在于并發(fā)數(shù)200后，處理時間已經(jīng)在5s以上，達到10s。獲取系統(tǒng)的各種表現(xiàn)。2. 當服務(wù)器出現(xiàn)資源泄露或者系統(tǒng)的資源耗盡等情況，點擊正確率小于95%，停止測試。穩(wěn)定性測試的用例如下：場景：（歷史數(shù)據(jù)有1000條以上）1. 使用Loadrunner模擬50個并發(fā)用戶請求交易，每個用戶有一定時間間隔（ThinkTime）1秒的情況下反復(fù)點擊頁面和信息檢索并返回結(jié)果，持續(xù)執(zhí)行812小時（20163117:302016328:30）每秒5次以上的點擊和檢索，記錄平均事務(wù)響應(yīng)時間，每秒事務(wù)數(shù)，吞吐量。測試方法：采用業(yè)務(wù)中合理、適度的用戶使用場景，對系統(tǒng)進行時間為812 小時的穩(wěn)定性測試。備注：以上測試均進行3次，來保證測試結(jié)果的有效性和準確性。3. 并發(fā)數(shù)改為700，重復(fù)上述測試步驟。場景：（歷史數(shù)據(jù)有1000條以上）1. 使用Loadrunner模擬300用戶請求交易，每個用戶沒有時間間隔（ThinkTime）的情況下反復(fù)提交交易并返回結(jié)果，持續(xù)時間分別為10分鐘， 20分鐘，30分鐘，記錄平均事務(wù)響應(yīng)時間，每秒事務(wù)數(shù)，吞吐量。
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1