【51CTO.com原創(chuàng)稿件】前幾天跟某互聯(lián)網(wǎng)主題旅游網(wǎng)架構(gòu)師聊起性能調(diào)優(yōu)的話題，那個(gè)時(shí)候正好遇到一些線上調(diào)優(yōu)的一些困惑，希望一起探討一下。

[[353487]] 

圖片來(lái)自 Pexels

他跟我說(shuō)，他們公司的系統(tǒng)從來(lái)沒(méi)有經(jīng)過(guò)性能調(diào)優(yōu)，功能測(cè)試完成后就上線了，線上也沒(méi)有出現(xiàn)過(guò)什么性能問(wèn)題呀，為什么要進(jìn)行調(diào)優(yōu)呢??

[[353488]] 

可謂底氣十足啊!!!無(wú)知者無(wú)畏啊;就不怕為公司埋雷，到時(shí)候追究他的責(zé)任?

當(dāng)時(shí)我一臉懵逼，既然不做性能優(yōu)化就直接上線，相當(dāng)于給系統(tǒng)埋了一個(gè)定時(shí)炸彈，一旦到某個(gè)臨界點(diǎn)，說(shuō)炸就炸，到時(shí)候回天乏力。

因此我就回答了他一句，“我去，如果你們公司做的是淘寶，京東，12306 這樣的網(wǎng)站，不做系統(tǒng)性能優(yōu)化就上線，試試看會(huì)是什么情況”。

今天，我們就從這個(gè)話題聊起，希望能跟你一起弄明白這幾個(gè)問(wèn)題：我們?yōu)槭裁匆鲂阅苷{(diào)優(yōu)?什么時(shí)候開(kāi)始做?做性能調(diào)優(yōu)是不是有標(biāo)準(zhǔn)可參考?

為什么要做性能調(diào)優(yōu)?

在互聯(lián)網(wǎng)項(xiàng)目開(kāi)發(fā)中，總是不斷針對(duì)新的需求去研發(fā)新的系統(tǒng)，而很多系統(tǒng)的設(shè)計(jì)都是可以觸類旁通的，在系統(tǒng)架構(gòu)設(shè)計(jì)中，我們必須遵循一些原則：

海恩法則：

• 事故的發(fā)生是量的積累的結(jié)果 (并發(fā)量，數(shù)據(jù)量，服務(wù)量…….)
• 再好的技術(shù)、再完美的規(guī)章， 在實(shí)際操作層面也無(wú)法取代人自身的素質(zhì)和責(zé)任心 。

墨菲定律：

• 任何事情都沒(méi)有表面看起來(lái)那么簡(jiǎn)單 。
• 所有事情的發(fā)展都會(huì)比你預(yù)計(jì)的時(shí)間長(zhǎng) 。
• 會(huì)出錯(cuò)的事總會(huì)出錯(cuò)。
• 如果你擔(dān)心某種情況發(fā)生，那么它更有可能發(fā)生。

這些原則警示我們，在互聯(lián)網(wǎng)公司里，對(duì)生產(chǎn)環(huán)境發(fā)生的任何怪異現(xiàn)象和問(wèn)題 都不要輕易忽視，對(duì)于其背后的原因一定要徹查。

同樣，海恩法則也強(qiáng)調(diào)任何嚴(yán)重事故的背后 都是多次小問(wèn)題的積累，積累到一定的量級(jí)后會(huì)導(dǎo)致質(zhì)變，嚴(yán)重的問(wèn)題就會(huì)浮出水面 。

那么，我們需要對(duì)線上服務(wù)產(chǎn)生的任何征兆，哪怕是一個(gè)小問(wèn)題，也要刨根問(wèn)底。

這就需要我們有技術(shù)攻關(guān)的能力，對(duì)任何現(xiàn)象都要秉著以下原則：為什么發(fā)生?發(fā)生了怎么應(yīng)對(duì)?怎么恢復(fù)?怎么避免?對(duì)問(wèn)題要徹查，不能因?yàn)閱?wèn)題的現(xiàn)象不明顯而忽略 。

一款線上產(chǎn)品如果沒(méi)有經(jīng)過(guò)性能測(cè)試，那它就好比是一顆定時(shí)炸彈，你不知道它什么時(shí)候會(huì)出現(xiàn)問(wèn)題，你也不清楚它能承受的極限在哪兒。

性能測(cè)試的目的在于驗(yàn)證軟件系統(tǒng)是否能夠達(dá)到用戶提出的性能指標(biāo)，同時(shí)發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸，以優(yōu)化軟件。

有些性能問(wèn)題是時(shí)間累積慢慢產(chǎn)生的，到了一定時(shí)間自然就爆炸了;而更多的性能問(wèn)題是由訪問(wèn)量的波動(dòng)導(dǎo)致的，例如，活動(dòng)或者公司產(chǎn)品用戶量上升。

當(dāng)然也有可能是一款產(chǎn)品上線后就半死不活，一直沒(méi)有大訪問(wèn)量，所以還沒(méi)有引發(fā)這顆定時(shí)炸彈。

現(xiàn)在假設(shè)你的系統(tǒng)要做一次促銷活動(dòng)，產(chǎn)品經(jīng)理或者老板告訴你預(yù)計(jì)有幾十萬(wàn)，幾百萬(wàn)，甚至更多的用戶訪問(wèn)量，詢問(wèn)系統(tǒng)能否承受得住這次活動(dòng)的壓力。

如果你不清楚自己系統(tǒng)的性能情況，也只能戰(zhàn)戰(zhàn)兢兢地回答老板，有可能大概沒(méi)問(wèn)題吧。

[[353489]] 

所以，要不要做性能調(diào)優(yōu)，這個(gè)問(wèn)題其實(shí)很好回答。所有的系統(tǒng)在開(kāi)發(fā)完之后，多多少少都會(huì)有性能問(wèn)題，我們首先要做的就是想辦法把問(wèn)題暴露出來(lái)，例如進(jìn)行壓力測(cè)試、模擬可能的操作場(chǎng)景等等，再通過(guò)性能調(diào)優(yōu)去解決這些問(wèn)題。

好的系統(tǒng)性能調(diào)優(yōu)不僅僅可以提高系統(tǒng)的性能，還能為公司節(jié)省資源，實(shí)現(xiàn)降本增效。這也是我們做性能調(diào)優(yōu)的最直接的目的。

什么時(shí)候開(kāi)始介入調(diào)優(yōu)?

解決了為什么要做性能優(yōu)化的問(wèn)題，那么新的問(wèn)題就來(lái)了：如果需要對(duì)系統(tǒng)做一次全面的性能監(jiān)測(cè)和優(yōu)化，我們從什么時(shí)候開(kāi)始介入性能調(diào)優(yōu)呢?是不是越早介入越好?

其實(shí)，在項(xiàng)目開(kāi)發(fā)的初期，我們沒(méi)有必要過(guò)于在意性能優(yōu)化，這樣反而會(huì)讓我們疲于性能優(yōu)化，不僅不會(huì)給系統(tǒng)性能帶來(lái)提升，還會(huì)影響到開(kāi)發(fā)進(jìn)度，甚至獲得相反的效果，給系統(tǒng)帶來(lái)新的問(wèn)題。

我們只需要在代碼層面保證有效的編碼，同時(shí)在架構(gòu)層面做好設(shè)計(jì)即可，具體架構(gòu)設(shè)計(jì)可以參考如下幾條行之有效的法則：

①系統(tǒng)的架構(gòu)設(shè)計(jì)，如何在架構(gòu)層面減少不必要的處理(網(wǎng)絡(luò)請(qǐng)求，數(shù)據(jù)庫(kù)操作等)，例如：使用 Cache 來(lái)減少 IO 次數(shù)，使用異步來(lái)增加單服務(wù)吞吐量，使用無(wú)鎖數(shù)據(jù)結(jié)構(gòu)來(lái)減少響應(yīng)時(shí)間。

②網(wǎng)絡(luò)拓?fù)鋬?yōu)化減少網(wǎng)絡(luò)請(qǐng)求時(shí)間、如何設(shè)計(jì)拓?fù)浣Y(jié)構(gòu)，分布式如何實(shí)現(xiàn)?

③系統(tǒng)代碼級(jí)別的代碼優(yōu)化，使用什么設(shè)計(jì)模式來(lái)進(jìn)行工作?哪些類需要使用單例，哪些需要盡量減少 new 操作?

④提高代碼層面的運(yùn)行效率、如何選取合適的數(shù)據(jù)結(jié)構(gòu)進(jìn)行數(shù)據(jù)存取?如何設(shè)計(jì)合適的算法?

⑤任務(wù)執(zhí)行方式級(jí)別的同異步操作，在哪里使用同步，哪里使用異步?

⑥JVM 調(diào)優(yōu)，如何設(shè)置 Heap、Stack、Eden 的大小，如何選擇 GC 策略，控制 Full GC 的頻率?

⑦服務(wù)端調(diào)優(yōu)(線程池，等待隊(duì)列)。

⑧數(shù)據(jù)庫(kù)優(yōu)化減少查詢修改時(shí)間。數(shù)據(jù)庫(kù)的選取?數(shù)據(jù)庫(kù)引擎的選取?數(shù)據(jù)庫(kù)表結(jié)構(gòu)的設(shè)計(jì)?數(shù)據(jù)庫(kù)索引、觸發(fā)器等設(shè)計(jì)?是否使用讀寫(xiě)分離?還是需要考慮使用數(shù)據(jù)倉(cāng)庫(kù)?

⑨緩存數(shù)據(jù)庫(kù)的使用，如何選擇緩存數(shù)據(jù)庫(kù)?是 Redis 還是 Memcache? 如何設(shè)計(jì)緩存機(jī)制?

⑩數(shù)據(jù)通信問(wèn)題，如何選擇通信方式?是使用 TCP 還是 UDP，是使用長(zhǎng)連接還是短連接?NIO 還是 BIO?netty、mina 還是原生 socket?

⑪操作系統(tǒng)選取，是使用 winserver 還是 Linux?或者 Unix?

⑫硬件配置?是 8G 內(nèi)存還是 32G，網(wǎng)卡 10G 還是 1G?例如：增加 CPU 核數(shù)如 32 核，升級(jí)更好的網(wǎng)卡如萬(wàn)兆，升級(jí)更好的硬盤(pán)如 SSD，擴(kuò)充硬盤(pán)容量如 2T，擴(kuò)充系統(tǒng)內(nèi)存如 128G。

在系統(tǒng)編碼完成之后，我們就可以對(duì)系統(tǒng)進(jìn)行性能測(cè)試了。這時(shí)候，產(chǎn)品經(jīng)理一般會(huì)提供線上預(yù)期數(shù)據(jù)，我們?cè)谔峁┑膮⒖计脚_(tái)上進(jìn)行壓測(cè)，通過(guò)性能分析、統(tǒng)計(jì)工具來(lái)統(tǒng)計(jì)各項(xiàng)性能指標(biāo)，看是否在預(yù)期范圍之內(nèi)。

在項(xiàng)目成功上線后，我們還需要根據(jù)線上的實(shí)際情況，依照日志監(jiān)控以及性能統(tǒng)計(jì)日志，來(lái)觀測(cè)系統(tǒng)性能問(wèn)題，一旦發(fā)現(xiàn)問(wèn)題，就要對(duì)日志進(jìn)行分析并及時(shí)修復(fù)問(wèn)題。

在我們進(jìn)行調(diào)優(yōu)之前，必須對(duì)性能指標(biāo)有一定的認(rèn)知，否則我們調(diào)優(yōu)就是空中樓閣，沒(méi)有任何的可參考的依據(jù)，是無(wú)法實(shí)現(xiàn)調(diào)優(yōu)的。

在我們了解性能指標(biāo)之前，我們先來(lái)了解下哪些計(jì)算機(jī)資源會(huì)成為系統(tǒng)的性能瓶頸，這些東西各位應(yīng)該都非常清楚，在系統(tǒng)上線后，無(wú)外乎就是 CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)等等這些問(wèn)題。

CPU：有的應(yīng)用需要大量計(jì)算，他們會(huì)長(zhǎng)時(shí)間、不間斷地占用 CPU 資源，導(dǎo)致其他資源無(wú)法爭(zhēng)奪到 CPU 而響應(yīng)緩慢，從而帶來(lái)系統(tǒng)性能問(wèn)題。

例如，代碼遞歸導(dǎo)致的無(wú)限循環(huán)，正則表達(dá)式引起的回溯，JVM 頻繁的 FULL GC，以及多線程編程造成的大量上下文切換等，這些都有可能導(dǎo)致 CPU 資源繁忙。

大量線程搶占 CPU 資源，導(dǎo)致 CPU 占用率升高：

CPU 占用率情況排查：

內(nèi)存：Java 程序一般通過(guò) JVM 對(duì)內(nèi)存進(jìn)行分配管理，主要是用 JVM 中的堆內(nèi)存來(lái)存儲(chǔ) Java 創(chuàng)建的對(duì)象。

系統(tǒng)堆內(nèi)存的讀寫(xiě)速度非常快，所以基本不存在讀寫(xiě)性能瓶頸。但是由于內(nèi)存成本要比磁盤(pán)高，相比磁盤(pán)，內(nèi)存的存儲(chǔ)空間又非常有限。

所以當(dāng)內(nèi)存空間被占滿，對(duì)象無(wú)法回收時(shí)，就會(huì)導(dǎo)致內(nèi)存溢出、內(nèi)存泄露等問(wèn)題。

磁盤(pán) I/O：磁盤(pán)相比內(nèi)存來(lái)說(shuō)，存儲(chǔ)空間要大很多，但磁盤(pán) I/O 讀寫(xiě)的速度要比內(nèi)存慢，雖然目前引入的 SSD 固態(tài)硬盤(pán)已經(jīng)有所優(yōu)化，但仍然無(wú)法與內(nèi)存的讀寫(xiě)速度相提并論。

網(wǎng)絡(luò)：網(wǎng)絡(luò)對(duì)于系統(tǒng)性能來(lái)說(shuō)，也起著至關(guān)重要的作用。如果你購(gòu)買(mǎi)過(guò)云服務(wù)，一定經(jīng)歷過(guò)，選擇網(wǎng)絡(luò)帶寬大小這一環(huán)節(jié)。

帶寬過(guò)低的話，對(duì)于傳輸數(shù)據(jù)比較大，或者是并發(fā)量比較大的系統(tǒng)，網(wǎng)絡(luò)就很容易成為性能瓶頸。

異常：Java 應(yīng)用中，拋出異常需要構(gòu)建異常棧，對(duì)異常進(jìn)行捕獲和處理，這個(gè)過(guò)程非常消耗系統(tǒng)性能。

如果在高并發(fā)的情況下引發(fā)異常，持續(xù)地進(jìn)行異常處理，那么系統(tǒng)的性能就會(huì)明顯地受到影響。

數(shù)據(jù)庫(kù)：大部分系統(tǒng)都會(huì)用到數(shù)據(jù)庫(kù)，而數(shù)據(jù)庫(kù)的操作往往是涉及到磁盤(pán) I/O 的讀寫(xiě)。

大量的數(shù)據(jù)庫(kù)讀寫(xiě)操作，會(huì)導(dǎo)致磁盤(pán) I/O 性能瓶頸，進(jìn)而導(dǎo)致數(shù)據(jù)庫(kù)操作的延遲性。

對(duì)于有大量數(shù)據(jù)庫(kù)讀寫(xiě)操作的系統(tǒng)來(lái)說(shuō)，數(shù)據(jù)庫(kù)的性能優(yōu)化是整個(gè)系統(tǒng)的核心。

鎖競(jìng)爭(zhēng)：在并發(fā)編程中，我們經(jīng)常會(huì)需要多個(gè)線程，共享讀寫(xiě)操作同一個(gè)資源，這個(gè)時(shí)候?yàn)榱吮３謹(jǐn)?shù)據(jù)的原子性(即保證這個(gè)共享資源在一個(gè)線程寫(xiě)的時(shí)候，不被另一個(gè)線程修改)，我們就會(huì)用到鎖。

鎖的使用可能會(huì)帶來(lái)上下文切換，從而給系統(tǒng)帶來(lái)性能開(kāi)銷。JDK1.6 之后，Java 為了降低鎖競(jìng)爭(zhēng)帶來(lái)的上下文切換，對(duì) JVM 內(nèi)部鎖已經(jīng)做了多次優(yōu)化，例如，新增了偏向鎖、自旋鎖、輕量級(jí)鎖、鎖粗化、鎖消除等。

而如何合理地使用鎖資源，優(yōu)化鎖資源，就需要你了解更多的操作系統(tǒng)知識(shí)、Java 多線程編程基礎(chǔ)，積累項(xiàng)目經(jīng)驗(yàn)，并結(jié)合實(shí)際場(chǎng)景去處理相關(guān)問(wèn)題。

了解了上面這些基本內(nèi)容，我們可以得到下面幾個(gè)指標(biāo)，來(lái)衡量一般系統(tǒng)的性能。

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

響應(yīng)時(shí)間是衡量系統(tǒng)性能的重要指標(biāo)之一，響應(yīng)時(shí)間越短，性能越好，一般一個(gè)接口的響應(yīng)時(shí)間是在毫秒級(jí)。

在系統(tǒng)中，我們可以把響應(yīng)時(shí)間自下而上細(xì)分為以下幾種：

• 數(shù)據(jù)庫(kù)響應(yīng)時(shí)間：數(shù)據(jù)庫(kù)操作所消耗的時(shí)間，往往是整個(gè)請(qǐng)求鏈中最耗時(shí)的。
• 服務(wù)端響應(yīng)時(shí)間：服務(wù)端包括 Nginx 分發(fā)的請(qǐng)求所消耗的時(shí)間以及服務(wù)端程序執(zhí)行所消耗的時(shí)間。
• 網(wǎng)絡(luò)響應(yīng)時(shí)間：這是網(wǎng)絡(luò)傳輸時(shí)，網(wǎng)絡(luò)硬件需要對(duì)傳輸?shù)恼?qǐng)求進(jìn)行解析等操作所消耗的時(shí)間。
• 客戶端響應(yīng)時(shí)間：對(duì)于普通的 Web、App 客戶端來(lái)說(shuō)，消耗時(shí)間是可以忽略不計(jì)的，但如果你的客戶端嵌入了大量的邏輯處理，消耗的時(shí)間就有可能變長(zhǎng)，從而成為系統(tǒng)的瓶頸。

吞吐量

在測(cè)試中，我們往往會(huì)比較注重系統(tǒng)接口的 TPS(每秒事務(wù)處理量)，因?yàn)?TPS 體現(xiàn)了接口的性能，TPS 越大，性能越好。

在系統(tǒng)中，我們也可以把吞吐量自下而上地分為兩種：

• 磁盤(pán)吞吐量
• 網(wǎng)絡(luò)吞吐量

我們先來(lái)看磁盤(pán)吞吐量，磁盤(pán)性能有兩個(gè)關(guān)鍵衡量指標(biāo)：

• 一種是 IOPS(Input/Output Per Second)，即每秒的輸入輸出量(或讀寫(xiě)次數(shù))，這種是指單位時(shí)間內(nèi)系統(tǒng)能處理的 I/O 請(qǐng)求數(shù)量，I/O 請(qǐng)求通常為讀或?qū)憯?shù)據(jù)操作請(qǐng)求，關(guān)注的是隨機(jī)讀寫(xiě)性能。適應(yīng)于隨機(jī)讀寫(xiě)頻繁的應(yīng)用。
• 另一種是數(shù)據(jù)吞吐量，這種是指單位時(shí)間內(nèi)可以成功傳輸?shù)臄?shù)據(jù)量。對(duì)于大量順序讀寫(xiě)頻繁的應(yīng)用，傳輸大量連續(xù)數(shù)據(jù)。

接下來(lái)看網(wǎng)絡(luò)吞吐量，這個(gè)是指網(wǎng)絡(luò)傳輸時(shí)沒(méi)有幀丟失的情況下，設(shè)備能夠接受的最大數(shù)據(jù)速率。

網(wǎng)絡(luò)吞吐量不僅僅跟帶寬有關(guān)系，還跟 CPU 的處理能力、網(wǎng)卡、防火墻、外部接口以及 I/O 等緊密關(guān)聯(lián)。

而吞吐量的大小主要由網(wǎng)卡的處理能力、內(nèi)部程序算法以及帶寬大小決定。

計(jì)算機(jī)資源分配使用率

通常由 CPU 占用率、內(nèi)存使用率、磁盤(pán) I/O、網(wǎng)絡(luò) I/O 來(lái)表示資源使用率。

這幾個(gè)參數(shù)好比一個(gè)木桶，如果其中任何一塊木板出現(xiàn)短板，任何一項(xiàng)分配不合理，對(duì)整個(gè)系統(tǒng)性能的影響都是毀滅性的。

負(fù)載承受能力

當(dāng)系統(tǒng)壓力上升時(shí)，你可以觀察，系統(tǒng)響應(yīng)時(shí)間的上升曲線是否平緩。這項(xiàng)指標(biāo)能直觀地反饋給你，系統(tǒng)所能承受的負(fù)載壓力極限。

例如，當(dāng)你對(duì)系統(tǒng)進(jìn)行壓測(cè)時(shí)，系統(tǒng)的響應(yīng)時(shí)間會(huì)隨著系統(tǒng)并發(fā)數(shù)的增加而延長(zhǎng)，直到系統(tǒng)無(wú)法處理這么多請(qǐng)求，拋出大量錯(cuò)誤時(shí)，就到了極限。

作者：航母哥

簡(jiǎn)介：目前就職于 58 研發(fā)中心擔(dān)任資深架構(gòu)師，負(fù)責(zé)消息中間件與全鏈路壓測(cè)的實(shí)施與落地。前阿里巴巴消息中間件資深研發(fā)，架構(gòu)師。擅長(zhǎng) Java 編程，對(duì)主流中間件 RocketMQ、Dubbo、ElasticJob、Netty、Sentienl、Mybatis、Mycat 等中間件有深入研究。

編輯：陶家龍

征稿：有投稿、尋求報(bào)道意向技術(shù)人請(qǐng)聯(lián)絡(luò)小編微信：gordonlonglong

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】