大家好，我是冰河~~

最近，很多小伙伴都在說，我沒做過性能優化的工作，在公司只是做些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 命中率,而應該聚焦性能瓶頸點
• 不盲從，測試、找到系統的性能瓶頸，再確定優化手段
• 注意權衡優化的成本和收益（有些優化可能需要現有架構做出調整、增加開發/運維成本）
• 優化的目標是用戶體驗、降低硬件成本（降低集群規模、不依賴單機高性能）
• 測試環境的優化手段未必對生產環境有效（優化需要針對真實情況）