接上文??《性能優(yōu)化那些事兒(一)》??

『不管項目大小，一旦上線，或多或少都會遇到性能問題』性能問題就像是魔咒一般藏繞著我們。

性能優(yōu)化應該什么時候開始

有些性能問題是隨著時間的積累慢慢產(chǎn)生的，比如系統(tǒng)一開始數(shù)據(jù)量很小的時候，沒有什么問題，等到數(shù)據(jù)積累到一定程度，問題就暴露出來了;有些問題是由于訪問量的過大造成的，比如系統(tǒng)平時沒問題，一到搞活動時就掛;也有些問題是遺留系統(tǒng)經(jīng)過太多人去維護修改，導致各種壞代碼味道性能問題仿佛到處存在。性能問題就如同一顆定時炸彈，只要數(shù)據(jù)量訪問量一上來，或者各個團隊在開發(fā)迭代中沒有注重性能的意識，早晚會炸。既然遲早會出問題，那我們應該什么時候開始進行性能優(yōu)化呢？是等出了問題后在進行優(yōu)化，還是在編碼的過程中就嘗試避免那些錯誤的代碼模式呢，或者采用一些手段盡可能的避免踩坑呢?

有人會說項目壓力大，如果開始過程中要考慮性能問題那么會影響進度。我覺得這是在給自己或者給后人挖坑，我們在一開始設計接口的時候，就應該考慮性能問題，不僅僅要考慮接口的合理性易用性，同時也要考慮接口是否有批量調用的情況。最簡單的方法，就是在設計接口的時候就直接設計批量接口，這樣這個接口又能支持批量又能支持單個，當然考慮到批量會有額外的工作要做，但總比出了問題到處去填坑強吧，這需要我們有能力識別未來業(yè)務上對批量的需求，并不是每個接口都需要支持批量操作。

我們還可以用很多方法來保證代碼質量以提高系統(tǒng)性能的，比如：

• 使用合理的數(shù)據(jù)結構和算法，比如，同樣是列表，LinkedList 就比 ArrayList 的插入性能高很多
• 多線程環(huán)境下合理選擇鎖的類型和使用場景
• 編寫高效 SQL、合理使用索引和事務來提升數(shù)據(jù)庫性能，使用ORM工具時注意N+1問題，有些看起來很便捷的方法請理解其細節(jié)再去使用。
• 多考慮接口的使用場景，是否有批量的可能，如果有提供批量接口
• 如果對性能要求很高，是否考慮使用Netty等異步手段

你的腦袋里應該有一大堆這樣的手段，在開發(fā)過程中，可以盡情發(fā)揮。但有一點需要著重強調：不要使用任何你不知道背后原理的優(yōu)化技巧。

這里有個有爭議的優(yōu)化手段：“不使用的對象應手動賦值為 NULL”有利于 GC 更早地回收內存，但在大多數(shù)場景下，不使用的局部變量是否設置為 NULL，對 GC 沒有任何影響，畢竟方法執(zhí)行完畢，棧幀就從操作數(shù)棧中彈出，方法中的局部變量就沒了，是否設置為 NULL 也就沒有任何影響。但是如果你是開發(fā)中間件的，或者某個復雜算法，那么手動設置為NULL確實在某些情況會有利于GC，比如臨時變量占用了大量內存當遇到『安全點』時如果不主動設置為NULL在JDK運行在『解釋』階段時確實會導致GC回收的比較慢。你可以在J.U.C包中經(jīng)?？吹絰xx=null，注釋都是help gc，但是我們經(jīng)常寫業(yè)務代碼的其實沒必要這么做。

在系統(tǒng)開發(fā)完成以后，可以根據(jù)一些預期的指標 ( 比如，并發(fā)數(shù) ) 和硬件資源來對系統(tǒng)進行測試，通過各種分析統(tǒng)計工具來判斷各項指標是否在預期范圍內。等到系統(tǒng)上線后，還要根據(jù)日志、監(jiān)控系統(tǒng)來觀測系統(tǒng)性能，一旦發(fā)現(xiàn)問題，就要及時分析并修復。這里可以使用的軟件很多，比如Dynatrace等各類APM工具，但如果你的系統(tǒng)比較定制也比較奇特的話，那么恐怕很難找到現(xiàn)成的工具，我們可以自己開發(fā)一套監(jiān)控系統(tǒng)，其實知道原理也很簡單的。

不管是新系統(tǒng)還是老系統(tǒng)，也不管是上線前還是上線后，做性能優(yōu)化都要遵循兩原則三步驟：

• 兩原則：不去優(yōu)化沒有測試的軟件(單元測試要有，不然優(yōu)化出了bug都不知道)、不去優(yōu)化你不了解的軟件
• 三步驟：測試、分析、調優(yōu)

性能測試的主要指標

一般來說，衡量系統(tǒng)的性能，主要有以下幾個指標：

響應時間

可以從端到端的響應時間細分下去：比如數(shù)據(jù)庫的響應時間，IO的響應時間，HTTPClient的響應時間。當我們優(yōu)化系統(tǒng)的時候，通過收集這些響應時間可以精確定位性能問題出現(xiàn)在哪。

并發(fā)數(shù)

并發(fā)數(shù)是指系統(tǒng)能夠同時處理請求的數(shù)量，這個數(shù)字也反映了系統(tǒng)的負載承受能力。

吞吐量

吞吐量是指單位時間內系統(tǒng)處理的請求數(shù)量，體現(xiàn)的是系統(tǒng)的處理能力。在 Web 系統(tǒng)中，常常用 TPS ( 每秒事務處理量 ) 或者 QPS ( 每秒查詢量 ) 來衡量系統(tǒng)的吞吐量。在不考慮網(wǎng)卡等網(wǎng)絡設備限制的情況下，可以使用下面的公式來大致估算系統(tǒng)的吞吐量：

吞吐量 = (1000/響應時間 ms) x 并發(fā)數(shù)

如何嚴謹?shù)刈鲂阅軠y試

那如何更嚴謹?shù)刈鲂阅軠y試?分享一個做性能測試比較科學的方法(來源自COOLSHELL)：

(1) 定義一個系統(tǒng)的響應時間 latency，建議是 TP99，以及成功率。比如路透的定義：99.9%的響應時間必須在 1ms 之內，平均響應時間在 1ms 以內，100%的請求成功。當然一般的 Web 系統(tǒng)不用定義的這么苛刻，99.9%的響應時間在 100ms 內即可。

(2) 在這個響應時間的限制下，來測試系統(tǒng)的吞吐量。測試用的數(shù)據(jù)，需要有大中小各種尺寸的數(shù)據(jù)，并可以混合。最好使用生產(chǎn)線上的測試數(shù)據(jù)。

(3) 在這個吞吐量做浸泡測試，比如：使用第二步測試得到的吞吐量連續(xù) 7 天的不間斷的壓測系統(tǒng)。然后收集 CPU，內存，硬盤/網(wǎng)絡 IO，等指標，查看系統(tǒng)是否穩(wěn)定，比如，CPU 是平穩(wěn)的，內存使用也是平穩(wěn)的。那么，這個值就是系統(tǒng)的性能。

() 找到系統(tǒng)的極限值。比如：在成功率 100%的情況下 (不考慮響應時間的長短)，系統(tǒng)能保持 10 分鐘的吞吐量。

(5) 做 Burst Test。用第二步得到的吞吐量執(zhí)行 5 分鐘，然后在第四步得到的極限值執(zhí)行 1 分鐘，再回到第二步的吞吐量執(zhí)行 5 分鐘，再到第四步的權限值執(zhí)行 1 分鐘，如此往復個一段時間，比如 2 天。收集系統(tǒng)數(shù)據(jù)：CPU、內存、硬盤/網(wǎng)絡 IO 等，觀察他們的曲線，以及相應的響應時間，確保系統(tǒng)是穩(wěn)定的。

(6) 低吞吐量和網(wǎng)絡小包的測試。有時候，在低吞吐量的時候，可能會導致延遲上升，比如 TCP_NODELAY 的參數(shù)沒有開啟會導致延遲上升，而網(wǎng)絡小包會導致帶寬用不滿也會導致性能上不去，所以，性能測試還需要根據(jù)實際情況有選擇的測試一下這兩個場景。

影響系統(tǒng)性能的主要因素

我們要先了解下一般情況哪些因素會影響到系統(tǒng)的性能，這樣我們可以逐個排查。

硬件

一般硬件是我們首先考慮的因素，如果可以提升硬件那么一般可以解決一些性能問題。常見的影響因素有CPU、內存、磁盤 I/O 、網(wǎng)絡等，如果內存不夠或者CPU長期滿負載那么就需要升級硬件了，如果業(yè)務中IO很重那么要考慮換個SSD硬盤，如果流量很大要考慮網(wǎng)絡帶寬夠不夠，網(wǎng)卡性能跟得上不。

系統(tǒng)

系統(tǒng)相關的點實在是太多了，這里簡單介紹幾種常見的情況：

• Linux文件描述符限制，有時候默認的值比較低，影響并發(fā)。
• Linux中Swap強烈建議關閉，打開壞處多于好處，會有意想不到的問題。
• 高流量的應用需要注意網(wǎng)卡中斷問題，使用CPU親和性綁定網(wǎng)卡。

軟件

一般有幾個因素需要重點關注

(1)數(shù)據(jù)庫：數(shù)據(jù)庫操作不僅涉及大量的內存以及 CPU 計算，還涉及到大量的磁盤讀寫。對數(shù)據(jù)庫的性能優(yōu)化是整個系統(tǒng)的核心，比如，我們常用的各種緩存都是為了減少對數(shù)據(jù)庫的壓力。開啟慢SQL搜集，通過分析慢SQL來優(yōu)化系統(tǒng)中效率低下的SQL語句。

(2)鎖競爭：單機環(huán)境下，鎖的使用可能會帶來大量的線程資源浪費，從而給系統(tǒng)帶來性能開銷;而分布式環(huán)境下，使用分布式鎖也可能造成大量的請求堆積，影響整個系統(tǒng)性能。優(yōu)化重心在于鎖粒度的控制，以及如何采用無鎖模型去替代。

(3)線程池：線程池的不恰當申明和配置也會帶來問題，請確保你的線程池都是有界的，確保你的線程池大小是合理的。

(4)異步系統(tǒng)與同步IO：確保你理解Netty相關知識，不要在Reactor線程中去使用同步IO。

(5)循環(huán)與外部請求：不要將外部請求放到循環(huán)中，而是應該盡可能通過批量方式一次請求。

(6)看似便利確暗藏殺機：很多庫提供了看似便利的方法，其實暗藏殺機，不要使用你不了解原理的所謂高級用法。

兜底策略

性能優(yōu)化做得再好，系統(tǒng)總會存在極限，因此，兜底的策略也是性能優(yōu)化的一部分，常見的兜底策略有限流、降級和熔斷。很多中間件都有這樣的功能，我們應當合理使用。還有我們可以通過減少涌入服務器的流量來避免高流量對我們服務器的沖擊，比如接入CDN，利用CDN的節(jié)點優(yōu)化和緩存能力能很好的優(yōu)化我們的性能，當然能使用更高級的邊緣計算技術那么在某些場景下會有質的飛躍。

需要著重強調的是任何的性能優(yōu)化都得結合業(yè)務場景明確已知的性能問題和性能目標，不能為了優(yōu)化而優(yōu)化。市面上有很多APM工具和性能分析工具可以幫助你定位性能問題，但如果你的系統(tǒng)非常的復雜且并不是標準容器，那么很可能你需要自己開發(fā)個APM工具來幫助你定位性能問題了，那么如何開發(fā)自己的性能分析工具呢，請聽下回分解。

接下文《??性能優(yōu)化那些事兒(三)??》