摘要：今天，我們就來說說在高併發場景下做效能優化有哪些衡量標準，以及做優化時需要注意哪些問題。最近，很多小夥伴都在說，我沒做過效能優化的工作，在公司只是做些crud的工作，接觸不到效能優化相關的工作。現在出去找工作面試的時候，面試官總是問些很刁鑽的問題來為難我，很多我都不會啊！那怎麼辦呢？那我就專門寫一些與高併發系統相關的面試容易問到的問題吧。今天，我們就來說說在高併發場景下做效能優化有哪些衡量標準，以及做優化時需要注意哪些問題。
首先，我們來分析下面試官的這個問題。其實，以我本人招聘面試的經驗來說，如果面試官問出了這樣的乙個問題。本質上不只是想讓面試者簡單的回答：做過或者沒做過。而是想通過這個簡單的問題來考察下面試者的思考能力和對於問題的理解能力。面試官本質上是想讓面試者通過這個問題，講述一下自己做效能優化相關工作的經驗、以及對於效能優化工作的一些理論的理解，比如就包括：效能優化的衡量指標，期間需要注意的問題等等。
如果面試者在面試過程中，不能充分理解面試官的意圖，回答問題時，像擠牙膏一樣，擠點出點，那麼，大多數情況下，面試官就會認為這個人沒啥效能優化的經驗。此時，面試者就會在面試官心理的印象大打折扣，面試結果就有非常大的概率涼涼了。
對於效能優化來說，衡量的指標有很多，大體上可以分為：效能指標、響應時間、併發量、秒開率和正確性等。我們可以使用下圖來表示這些衡量指標。
接下來，我們就分別說明下這些衡量指標。
效能指標又可以包含：吞吐量和響應速度。我們平時所說的qps、tps和hps等，就可以歸結為吞吐量。有很多小夥伴可能對於qps、tps和hps等不太了解，我們先來說下這幾個字母的含義。
這些都是與吞吐量相關的衡量指標。
平時我們在做優化工作的時候，首先要明確需要優化的事項。比如：我們做的優化工作是要提高系統的吞吐量？還是要提公升系統的響應速度呢？舉乙個具體點的例子：比如我們的程式中存在一些資料庫或者快取的批量操作，雖然在資料的讀取上，響應速度下降了，但是我們優化的目標就是吞吐量，只要我們優化後系統的整體吞吐量明顯上公升了，那這也是提公升了程式的效能。
所以說，優化效能不只是提公升系統的響應速度。
這裡，優化效能也並不是一味的優化吞吐量和優化響應速度，而是在吞吐量和響應速度之間找到乙個平衡點，使用有限的伺服器資源來更好的提公升使用者體驗。
對於響應時間來說，有兩個非常重要的衡量指標。那就是：平均響應時間和百分位數。
（1）平均響應時間
通常，平均響應時間體現的是服務介面的平均處理能力。計算方式就是把所有的請求所耗費的時間加起來，然後除以請求的次數。舉個簡單的例子：比如：我們向乙個**傳送了5次請求，每次請求所耗費的時間分別為：1ms，2ms，1ms，3ms，2ms，那麼，平均響應時間就是（1+2+1+3+2）/ 5 = 1.8ms，所以，平均響應時間就是1.8ms。
平均響應時間這個指標存在乙個問題：如果在短時間內請求變得很慢，但很快過去了，此時使用平均響應時間就無法很好的體現出效能的波動問題。
（2）百分位數
百分位數就是我們在優化的時候，圈定乙個時間範圍，把每次請求的耗時加入乙個列表中，然後按照從小到大的順序將這些時間進行排序。這樣，我們取出特定百分位的耗時，這個數字就是 tp 值。
tp值表示的含義就是：超過 n% 的請求都在 x 時間內返回。比如 tp90 = 50ms，意思是超過 90th 的請求，都在 50ms 內返回。
百分位數這個指標也是很重要的，它反映的是應用介面的整體響應情況。
我們一般會將百分位數分為 tp50、tp90、tp95、tp99、tp99.9 等多個段，對高百分位的值要求越高，對系統響應能力的穩定性要求越高。
併發量指的是系統能夠同時處理的請求數量，反映的是系統的負載能力。
我們在對高併發系統進行優化的時候，往往也會在併發量上進行調優，調優方式也是多種多樣的，目的就是提高系統同時處理請求的能力。
總體來說，併發量這個指標理解起來還是比較簡單的，我就不做過多的描述了。
正確性說的是無論我們以何種方式，何種手段對應用進行優化，優化後的互動資料結果必須是正確的。不能出現優化前效能比較低，資料正確，而優化後效能比較高，反而資料不正確的現象。
點選關注，第一時間了解華為雲新鮮技術~
效能測試 響應時間 併發 RPS的關係
寫這篇文章是為了幫自己理清一下效能測試中最最基本，卻總是被人忽略的一些概念。併發 什麼叫併發？併發不是我們理解的在loadrunner場景中設定併發數，而是正在系統中執行操作或者在系統的佇列中排隊的使用者數，當然在lr的世界裡，我們也會粗略的認為二者相等。所以我們通常把響應時間認為是伺服器處理請求所...
效能測試 響應時間 併發 RPS的關係
寫這篇文章是為了幫自己理清一下效能測試中最最基本，卻總是被人忽略的一些概念。併發 什麼叫併發？併發不是我們理解的在loadrunner場景中設定併發數，而是正在系統中執行操作或者在系統的佇列中排隊的使用者數，當然在lr的世界裡，我們也會粗略的認為二者相等。所以我們通常把響應時間認為是伺服器處理請求所...
效能測試之 響應時間
響應時間 網路傳輸時間 請求 伺服器處理時間 一層或是多層 網路傳輸時間 響應 頁面前段解析時間 響應時間 呈現時間 網路傳輸時間 伺服器端響應時間 應用延時時間 呈現時間 其實主要說的瀏覽器對接收到資料的乙個處理展示的過程。幾年前大家都在用ie，如果頁面顯示比較慢，我們肯定不會怪罪ie，只會怪罪電...