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

[[353487]] 

圖片來自 Pexels

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

[[353488]] 

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

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

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

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

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

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

海恩法則：

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

墨菲定律：

• 任何事情都沒有表面看起來那么簡單 。
• 所有事情的發(fā)展都會比你預(yù)計的時間長 。
• 會出錯的事總會出錯。
• 如果你擔心某種情況發(fā)生，那么它更有可能發(fā)生。

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

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

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

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

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

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

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

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

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

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

[[353489]] 

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

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

什么時候開始介入調(diào)優(yōu)?

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

其實，在項目開發(fā)的初期，我們沒有必要過于在意性能優(yōu)化，這樣反而會讓我們疲于性能優(yōu)化，不僅不會給系統(tǒng)性能帶來提升，還會影響到開發(fā)進度，甚至獲得相反的效果，給系統(tǒng)帶來新的問題。

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

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

②網(wǎng)絡(luò)拓撲優(yōu)化減少網(wǎng)絡(luò)請求時間、如何設(shè)計拓撲結(jié)構(gòu)，分布式如何實現(xiàn)?

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

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

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

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

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

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

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

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

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

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

在系統(tǒng)編碼完成之后，我們就可以對系統(tǒng)進行性能測試了。這時候，產(chǎn)品經(jīng)理一般會提供線上預(yù)期數(shù)據(jù)，我們在提供的參考平臺上進行壓測，通過性能分析、統(tǒng)計工具來統(tǒng)計各項性能指標，看是否在預(yù)期范圍之內(nèi)。

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

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

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

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

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

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

CPU 占用率情況排查：

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

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

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

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

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

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

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

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

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

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

對于有大量數(shù)據(jù)庫讀寫操作的系統(tǒng)來說，數(shù)據(jù)庫的性能優(yōu)化是整個系統(tǒng)的核心。

鎖競爭：在并發(fā)編程中，我們經(jīng)常會需要多個線程，共享讀寫操作同一個資源，這個時候為了保持數(shù)據(jù)的原子性(即保證這個共享資源在一個線程寫的時候，不被另一個線程修改)，我們就會用到鎖。

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

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

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

響應(yīng)時間

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

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

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

吞吐量

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

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

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

我們先來看磁盤吞吐量，磁盤性能有兩個關(guān)鍵衡量指標：

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

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

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

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

計算機資源分配使用率

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

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

負載承受能力

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

例如，當你對系統(tǒng)進行壓測時，系統(tǒng)的響應(yīng)時間會隨著系統(tǒng)并發(fā)數(shù)的增加而延長，直到系統(tǒng)無法處理這么多請求，拋出大量錯誤時，就到了極限。

作者：航母哥

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

編輯：陶家龍

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

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