性能分析之響應時間

響應時間(response time)作為性能測試過程中重要指標之一,是測試工程師重點關注的。

響應時間有兩種理解，一是應用系統從請求發出開始到客戶端收到響應所消耗的時間，二是應用系統從請求發出開始到客戶端接收到最后一個字節數據所消耗的時間。從用戶角度看，響應時間是用戶感受系統性能的主要體現，既有客觀成分又有主觀成分。

性能分析之響應時間

響應時間構成
頁面的服務端響應時間可以切分為呈現時間、網絡傳輸時間、系統處理時間。

呈現時間是流量器對接收到數據的一個處理展現所消耗的時間，主要差別在瀏覽器、用戶自身電腦配置的差異上；網絡傳輸時間，如果涉及廣域網，大多情況都會有5ms-50ms的延時；如果是局域網普遍延時都在1ms以內，幾乎可以忽略不計。為了避免網絡延時，建議應用系統的服務器部署在同一局域網中。

呈現時間和網絡傳輸時間都是不可控制的，用戶使用的電腦及瀏覽器、網絡情況千差萬別，唯一能控制的就是將系統的處理請求的時間縮到最短。

?

系統處理時間
系統得到請求后對請求進行處理并將結果返回，如果要分析系統的處理能力涉及語言、語言框架、中間件、數據庫、系統架構及服務器系統等內容。通常情況，系統處理的時間消耗主要是在數據庫的讀取上，可以重點分析SQL語句，分析數據庫的表、索引設計是否合理，以及SQL實現算法是否可優化、復雜業務邏輯是否合理、日志打印等。

?

合理的響應時間
在進行性能測試時，“合理的響應時間”取決于用戶的需求，而不能依據測試人員自己設想來決定。對于響應時間范圍，有一個普遍的標準：早期是2/5/10秒原則，如今隨著技術的發展，用戶的要求也提高了，逐漸朝1/3/5秒原則演變。

1/3/5秒原則：

在1s以內得到響應，用戶會覺得系統響應很快，體驗非常好；1-3秒得到響應，用戶可以接收，體驗還不錯；3-5秒才響應，用戶就感覺慢了，體驗有點糟糕；一旦響應超過5秒，用戶就會認為是個失敗的體驗，選擇離開或重新發起請求。

但是對于不同的業務系統，用戶可接受的響應時間是不一樣，需要針對自己的業務場景來做統計量化的工作。

確定系統功能和使用路徑；
收集性能目標；（調查客戶對響應時間的滿意值）
量化性能目標（包括分解性能目標、量化各部分性能目標）；
滿足性能目標。
在經過了這些步驟之后，才能讓我們明確響應時間這個指標

總結

以上是生活随笔為你收集整理的性能测试，响应时间的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。