## 寫在前面 > 最近，很多小夥伴都在說，我沒做過效能優化的工作，在公司只是做些CRUD的工作，接觸不到效能優化相關的工作。現在出去找工作面試的時候，面試官總是問些很刁鑽的問題來為難我，很多我都不會啊！那怎麼辦呢？那我就專門寫一些與高併發系統相關的面試容易問到的問題吧。今天，我們就來說說在高併發場景下做效能優化有哪些衡量標準，以及做優化時需要注意哪些問題。 ## 面試場景 **面試官：平時工作中有沒有做過一些效能優化相關的工作呢？** 首先，我們來分析下面試官的這個問題。其實，以我本人招聘面試的經驗來說，如果面試官問出了這樣的一個問題。本質上不只是想讓面試者簡單的回答：做過或者沒做過。而是想通過這個簡單的問題來考察下面試者的思考能力和對於問題的理解能力。面試官本質上是想讓面試者通過這個問題，講述一下自己做效能優化相關工作的經驗、以及對於效能優化工作的一些理論的理解，比如就包括：效能優化的衡量指標，期間需要注意的問題等等。 如果面試者在面試過程中，不能充分理解面試官的意圖，回答問題時，像擠牙膏一樣，擠點出點，那麼，大多數情況下，面試官就會認為這個人沒啥效能優化的經驗。此時，面試者就會在面試官心理的印象大打折扣，面試結果就有非常大的概率涼涼了。  ## 衡量指標 對於效能優化來說，衡量的指標有很多，大體上可以分為：效能指標、響應時間、併發量、秒開率和正確性等。我們可以使用下圖來表示這些衡量指標。  接下來，我們就分別說明下這些衡量指標。 ### 效能指標 效能指標又可以包含：吞吐量和響應速度。我們平時所說的QPS、TPS和HPS等，就可以歸結為吞吐量。有很多小夥伴可能對於QPS、TPS和HPS等不太瞭解，我們先來說下這幾個字母的含義。 * QPS代表的是每秒的查詢數量。 * TPS代表的是每秒事務的數量。 * HPS代表的是每秒的HTTP請求數量。 這些都是與吞吐量相關的衡量指標。 平時我們在做優化工作的時候，首先要明確需要優化的事項。比如：我們做的優化工作是要提高系統的吞吐量？還是要提升系統的響應速度呢？舉一個具體點的例子：比如我們的程式中存在一些資料庫或者快取的批量操作，雖然在資料的讀取上，響應速度下降了，但是我們優化的目標就是吞吐量，只要我們優化後系統的整體吞吐量明顯上升了，那這也是提升了程式的效能。 **所以說，優化效能不只是提升系統的響應速度。** 這裡，優化效能也並不是一味的優化吞吐量和優化響應速度，而是在吞吐量和響應速度之間找到一個平衡點，使用有限的伺服器資源來更好的提升使用者體驗。 ### 響應時間 對於響應時間來說，有兩個非常重要的衡量指標。那就是：**平均響應時間和百分位數。** **（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 等多個段，對高百分位的值要求越高，對系統響應能力的穩定性要求越高。 ### 併發量 併發量指的是系統能夠同時處理的請求數量，反映的是系統的負載能力。 我們在對高併發系統進行優化的時候，往往也會在併發量上進行調優，調優方式也是多種多樣的，目的就是提高系統同時處理請求的能力。 總體來說，併發量這個指標理解起來還是比較簡單的，我就不做過多的描述了。 ### 秒開率 秒開率主要針對的是前端網頁或者移動端APP來說的，如果一個前端網頁或者APP能夠在1秒內很平滑的開啟，尤其是首頁的載入。此時，使用者就會感到前端網頁或者APP使用起來很順暢，如果超過3秒甚至更長的時間，使用者就有可能會直接退出前端網頁或者APP不再使用。 所以，在高併發場景下優化程式，不只要對後端程式進行優化，對於前端和APP也是要進行優化的。 ### 正確性 正確性說的是無論我們以何種方式，何種手段對應用進行優化，優化後的互動資料結果必須是正確的。不能出現優化前效能比較低，資料正確，而優化後效能比較高，反而資料不正確的現象。 ## 優化需要注意的問題  - 除非必要,一開始不要優化(尤其是開發階段) - 有些優化準則已經過時,需要考慮當下的軟硬體環境(不要墨守成規) - 不要過分強調某些系統級指標,如cache 命中率,而應該聚焦效能瓶頸點 - 不盲從，測試、找到系統的效能瓶頸，再確定優化手段 - 注意權衡優化的成本和收益（有些優化可能需要現有架構做出調整、增加開發/運維成本） - 優化的目標是使用者體驗、降低硬體成本（降低叢集規模、不依賴單機高效能） - 測試環境的優化手段未必對生產環境有效（優化需要針對真實情況） ## 重磅福利 關注「 **冰河技術** 」微信公眾號，後臺回覆 “**設計模式**” 關鍵字領取《**深入淺出Java 23種設計模式**》PDF文件。回覆“**Java8**”關鍵字領取《**Java8新特性教程**》PDF文件。回覆“**限流**”關鍵字獲取《**億級流量下的分散式限流解決方案**》PDF文件，三本PDF均是由冰河原創並整理的超硬核教程，面試必備！！ **好了，今天就聊到這兒吧！別忘了點個贊，給個在看和轉發，讓更多的人看到，一起學習，一起進步！！** ## 寫在最後 > 如果你覺得冰河寫的還不錯，請微信搜尋並關注「 **冰河技術** 」微信公眾號，跟冰河學習高併發、分散式、微服務、大資料、網際網路和雲原生技術，「 **冰河技術** 」微信公眾號更新了大量技術專題，每一篇技術文章乾貨滿滿！不少讀者已經通過閱讀「 **冰河技術** 」微信公眾號文章，吊打面試官，成功跳槽到大廠；也有不少讀者實現了技術上的飛躍，成為公司的技術骨幹！如果你也想像他們一樣提升自己的能力，實現技術能力的飛躍，進大廠，升職加薪，那就關注「 **冰河技術** 」微信公眾號吧，每天更新超硬核技術乾貨，讓你對如何提升技術能力不再迷茫！ ![](https://img-blog.csdnimg.cn/202009060137158