論性能測試中的“響應時間”

1，“系統響應時間”如何定義？是指“客戶端接收到響應所消耗的時間”還是“接收到最后一個字節數據所消耗的時間。。。?！?？

2，書中提到“可以使用技巧在數據尚未接收完成時進行呈現來減少用戶感受到的響應時間”，這一句話是什么意思？

先回答第一個問題，我在書中找到了原文：

而“系統響應時間”指應用系統從請求發出開始到客戶端接收到數據所消耗的時間。
這里確實有不明確的地方，更確切的說法應該是：而“系統響應時間”指應用系統從請求發出開始到客戶端接收到所有數據所消耗的時間。

這樣，“系統響應時間”加上“呈現時間”，才是完整的用戶感受到的響應時間。

對于第二個問題，倒是有些可以討論的內容：

我們在定義響應時間的時候，是從應用的使用者/客戶的角度出發的。從這個角度出發，響應時間被定義成“對請求做出響應所需要的時間”。我們以一個web應 用為例，假設web應用有一個“提交用戶留言”的功能，考察這個功能的響應時間，就應該是“從用戶填寫完留言，點擊提交按鈕開始，到頁面刷新完成，用戶看 到完整的返回頁面為止”所消耗的所有時間——這個定義非常完整，但若從用戶的實際感受來看的話，這里還是有一點模糊的地方。

我們可以把上文提到的交互過程細化一下：

用戶點擊“提交”按鈕-》請求被發送到服務器-》服務器處理-》服務器返回頁面-》瀏覽器接收服務器的返回并render頁面

模糊之處在于最后一個環節：“瀏覽器接收服務器的返回并render頁面”，如果我們堅定的認為“只有當頁面完整的顯示完成，才是響應時間的結束”，這不 會是一個問題。但實際上，對大多數用戶來說，看到頁面上開始顯示數據或是圖片，用戶就會認為“我已經得到了響應”，從這個角度來說，用戶感受到的響應時間 實際上是“從請求發出開始，到用戶看到頁面開始呈現出的內容結束”所需要的時間。

那為什么我們不采用“從請求發出開始，到用戶看到頁面開始呈現出的內容結束”這樣一個定義方式呢？關鍵在于這里涉及到用戶的認知行為，帶有主觀色彩，不完 全是客觀的標準，因此不適合作為一個需要被度量的性能指標。另一方面，不同的瀏覽器有不同的行為（例如parse的方式和render的方式），如果需要 把這些瀏覽器本身的行為都考慮到性能測試中的話，我們很難為所有的系統建立統一的測試模型——實際上，現在的主流性能測試工具（例如JMeter， LoadRunner，Webload等）都完全不考慮客戶端的呈現過程。

原文轉自：http://www.anti-gravitydesign.com