隨著吞吐量的增大，響應時間會逐漸變長，當達到最大吞吐量之後，響應時間會開始急劇飆公升，尤其是後面堆積佇列中等待的請求
如果僅僅是關注平均值，由於大部分請求的響應時間還是相對較短，有一部分介面可能是10ms級別，慢請求往往只佔乙個很小的比例，所以從平均值中分析資料時，慢響應的介面響應時間被平均了。但實際上，可能有超過1%，或者5%請求的響應時間已經遠遠超出目標響應資料的範圍
效能測試中，更科學合理的指標是關注tp95或者tp99響應時間（tp是top percentile縮寫），即我們平時說的95線或者99線響應時間，用來描述一組響應時間的分布特徵。以tp95為例，假設有100個響應時間，從小到大排序之後，第95個響應時間的值就是這組響應時間的tp95值，表示至少有95%的數字是小於或者等於這個值
效能測試之 響應時間
響應時間 網路傳輸時間 請求 伺服器處理時間 一層或是多層 網路傳輸時間 響應 頁面前段解析時間 響應時間 呈現時間 網路傳輸時間 伺服器端響應時間 應用延時時間 呈現時間 其實主要說的瀏覽器對接收到資料的乙個處理展示的過程。幾年前大家都在用ie，如果頁面顯示比較慢，我們肯定不會怪罪ie，只會怪罪電...
效能測試基礎（五）響應時間
站在使用者角度來說，你可以將軟體效能看作是軟體對使用者操作的響應時間。說得更明直白點，對使用者來說，當單擊乙個按鈕或鏈結，從使用者單擊開始到應用系統把本次操作的結果以使用者識別的方式展示出來，這個過程所消耗的時間就是使用者對軟體效能的直觀印象。我們需要對這個過程進行分解，才能得到你真正想要的響應時間...
效能測試 響應時間 併發 RPS的關係
寫這篇文章是為了幫自己理清一下效能測試中最最基本，卻總是被人忽略的一些概念。併發 什麼叫併發？併發不是我們理解的在loadrunner場景中設定併發數，而是正在系統中執行操作或者在系統的佇列中排隊的使用者數，當然在lr的世界裡，我們也會粗略的認為二者相等。所以我們通常把響應時間認為是伺服器處理請求所...