響應時間過程分析:
我們需要對這個過程進行分解，才能得到你真正想要的響應時間。我把整個過程分三個部分：呈現時間，數據傳輸時間和系統處理時間。
呈現時間
其實主要說的瀏覽器對接收到數據的一個處理展示的過程。幾年前大家都在用IE，如果頁面顯示比較慢，我們肯定不會怪罪IE，只會怪罪電信運營商的網速或被訪問的系統（其實，大多情況我們不會考慮是被訪問系統的問題）。現在Chrome來了，我們會發現同一台電腦同一個網站，通過Chrome去訪問，頁面的呈現速度會比IE略快。這是各種評測及大眾用戶的整體感受。
當然，我說這個呈現時間不能全怪在瀏覽器的身上，當然還和承載它的操作系統有關，以及電腦硬件（比如CPU、 內存）。假如你有超快的瀏覽器，如果是一台配置很低的電腦上運行，當你多打開幾個網頁就有可能使電腦卡死。
數據傳輸時間
千萬不要忽視數據傳輸時間。如果你要寄信給你一個遠方的朋友，你想是什么影響你朋友收到信的時間的？不是你寫信的過程（如果你寫的信不像書一樣厚的話），也不是你朋友讀信的過程，而是送信的過程。
拿我們系統的數據傳輸過程來說，我們發送一個請求需要時間，系統處理完后返回給我們也需要時間。初學性能測試工具的同學喜歡拿工具去測試互聯網上的一些系統，甚至不懂性能的同學認為可以用性能測試工具將互聯網上的一些網站宕機。
那么，我覺得這些同學應該補補網絡知識了，你的帶寬是多少？互聯網是個網，就是算是相同的起點與終點，它有可能走的不同的路線。有沒有考慮網絡延遲？就算你的發出請求都能成功的發出，但到目的地的時候，已經不能叫並發了。
這也是為什么我們在一般做性能測試時，一般要強調要在局域網中進行。當然，有些性能測試需要在互聯網中時行。但它們重點不是驗證服務器端的最大處理能力。
系統處理時間
當系統得到請求后會對請求進行處理並將結果返回。那我進行性能測試主要就是驗證系統的處理時間，因為前面的呈現時間和數據傳輸時間都是我們不可控制的，用戶使用的電腦及瀏覽器千差萬別，用戶的網絡狀況千差萬別。我們唯一能控制的就是將系統的處理請求的時間縮到最短。 一般性能測試場景
聽了上面的分析，貌似每個過程都挺“浪費”時間，那么我們如何只測試系統的處理時間呢？
一般測試工具都屏蔽響應的呈現過程，只是模擬多用戶並發請求，計算用戶得到響應的時間，不會將服務器的每個響應做客戶端渲染呈現。
對於數據傳輸的問題，這也是我要強調的性能測試要在局域網中進行，在局域網中一般不會受到數據帶寬的限制。所以，可以對數據的傳輸時間忽略不計。