性能優化作為進大廠的必備技能，也是區分中高級程序員、架構師水平的重要依據。從今天開始，冰河帶著大家一起學習一個新的技術專欄，那就是《性能優化》專欄，也就是從今天往后的一段時間內，我們一起深入探討性能優化相關的原理、技術、知識和實踐。希望各位小伙伴通過此專欄的學習，能夠徹底吃透性能優化，突破自身的技術瓶頸，進入心儀的大廠。

衡量指標

對于性能優化來說，衡量的指標有很多，大體上可以分為：性能指標、響應時間、并發量、秒開率和正確性等。我們可以使用下圖來表示這些衡量指標。

接下來，我們就分別說明下這些衡量指標。

性能指標

性能指標又可以包含：吞吐量和響應速度。我們平時所說的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 命中率,而應該聚焦性能瓶頸點
• 不盲從，測試、找到系統的性能瓶頸，再確定優化手段
• 注意權衡優化的成本和收益（有些優化可能需要現有架構做出調整、增加開發/運維成本）
• 優化的目標是用戶體驗、降低硬件成本（降低集群規模、不依賴單機高性能）
• 測試環境的優化手段未必對生產環境有效（優化需要針對真實情況）