站在使用者角度來說，你可以將軟體效能看作是軟體對使用者操作的響應時間。說得更明直白點，對使用者來說，當單擊乙個按鈕或鏈結，從使用者單擊開始到應用系統把本次操作的結果以使用者識別的方式展示出來，這個過程所消耗的時間就是使用者對軟體效能的直觀印象。
我們需要對這個過程進行分解，才能得到你真正想要的響應時間。我把整個過程分三個部分：呈現時間，資料傳輸時間和系統處理時間。
其實主要說的瀏覽器對接收到資料的乙個處理展示的過程。幾年前大家都在用ie，如果頁面顯示比較慢，我們肯定不會怪罪ie，只會怪罪電信運營商的網速或被訪問的系統（其實，大多情況我們不會考慮是被訪問系統的問題）。現在chrome來了，我們會發現同一臺電腦同乙個**，通過chrome去訪問，頁面的呈現速度會比ie略快。這是各種評測及大眾使用者的整體感受。
當然，我說這個呈現時間不能全怪在瀏覽器的身上，當然還和承載它的作業系統有關，以及電腦硬體（比如cpu、 記憶體）。假如你有超快的瀏覽器，如果是一台配置很低的電腦上執行，當你多開啟幾個網頁就有可能使電腦卡死。
千萬不要忽視資料傳輸時間。如果你要寄信給你乙個遠方的朋友，你想是什麼影響你朋友收到信的時間的？不是你寫信的過程（如果你寫的信不像書一樣厚的話），也不是你朋友讀信的過程，而是送信的過程。
那麼，我覺得這些同學應該補補網路知識了，你的頻寬是多少？網際網路是個網，就是算是相同的起點與終點，它有可能走的不同的路線。有沒有考慮網路延遲？就算你的發出請求都能成功的發出，但到目的地的時候，已經不能叫併發了。
這也是為什麼我們在一般做效能測試時，一般要強調要在區域網中進行。當然，有些效能測試需要在網際網路中時行。但它們重點不是驗證伺服器端的最大處理能力。
當系統得到請求後會對請求進行處理並將結果返回。那我進行效能測試主要就是驗證系統的處理時間，因為前面的呈現時間和資料傳輸時間都是我們不可控制的，使用者使用的電腦及瀏覽器千差萬別，使用者的網路狀況千差萬別。我們唯一能控制的就是將系統的處理請求的時間縮到最短。 一般效能測試場景
聽了上面的分析，貌似每個過程都挺「浪費」時間，那麼我們如何只測試系統的處理時間呢？
一般測試工具都遮蔽響應的呈現過程，只是模擬多使用者併發請求，計算使用者得到響應的時間，不會將伺服器的每個響應做客戶端渲染呈現。
對於資料傳輸的問題，這也是我要強調的效能測試要在區域網中進行，在區域網中一般不會受到資料頻寬的限制。所以，可以對資料的傳輸時間忽略不計。
效能測試之 響應時間
響應時間 網路傳輸時間 請求 伺服器處理時間 一層或是多層 網路傳輸時間 響應 頁面前段解析時間 響應時間 呈現時間 網路傳輸時間 伺服器端響應時間 應用延時時間 呈現時間 其實主要說的瀏覽器對接收到資料的乙個處理展示的過程。幾年前大家都在用ie，如果頁面顯示比較慢，我們肯定不會怪罪ie，只會怪罪電...
效能測試 99線響應時間
隨著吞吐量的增大，響應時間會逐漸變長，當達到最大吞吐量之後，響應時間會開始急劇飆公升，尤其是後面堆積佇列中等待的請求 如果僅僅是關注平均值，由於大部分請求的響應時間還是相對較短，有一部分介面可能是10ms級別，慢請求往往只佔乙個很小的比例，所以從平均值中分析資料時，慢響應的介面響應時間被平均了。但實...
效能測試 響應時間 併發 RPS的關係
寫這篇文章是為了幫自己理清一下效能測試中最最基本，卻總是被人忽略的一些概念。併發 什麼叫併發？併發不是我們理解的在loadrunner場景中設定併發數，而是正在系統中執行操作或者在系統的佇列中排隊的使用者數，當然在lr的世界裡，我們也會粗略的認為二者相等。所以我們通常把響應時間認為是伺服器處理請求所...