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

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

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

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

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

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

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

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

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

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

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

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

性能測試的主要指標(biāo)

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

響應(yīng)時(shí)間

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

并發(fā)數(shù)

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

吞吐量

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

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

如何嚴(yán)謹(jǐn)?shù)刈鲂阅軠y試

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

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

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

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

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

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

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

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

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

硬件

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

系統(tǒng)

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

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

軟件

一般有幾個(gè)因素需要重點(diǎn)關(guān)注

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

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

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

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

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

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

兜底策略

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

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

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