[[347347]]

前幾天，和一個(gè)同學(xué)瞎聊，他說，“我們公司的系統(tǒng)從來都沒有經(jīng)過性能調(diào)優(yōu)，集成測(cè)試沒問題后就上線了，上線后也幾乎沒出現(xiàn)過性能問題。”

我當(dāng)時(shí)沒回他。因?yàn)闆]遇到性能問題不代表程序不存在性能問題，只能說明系統(tǒng)的訪問量有點(diǎn)小。有印象吧?每次明星爆出個(gè)大瓜，微博就掛了，那就是因?yàn)槎虝r(shí)間內(nèi)訪問量暴增后，扛不住壓力，出現(xiàn)了性能瓶頸。

大部分的性能問題都是由于訪問量過大導(dǎo)致的，我記得汪峰在京東做過一次直播，那畫面卡成狗，幾乎沒法下單，畫面都出不來。因?yàn)榫〇|之前沒做過直播，沒遇到這么大訪問量，估計(jì)那次活動(dòng)結(jié)束后，直播方面的開發(fā)沒少挨批。

還有一部分性能問題是隨著時(shí)間積累爆發(fā)的，程序在服務(wù)器上運(yùn)行一段時(shí)間后就要重啟，否則某個(gè)時(shí)間節(jié)點(diǎn)內(nèi)存就突然爆掉了。反正我司一些項(xiàng)目就遇到過這方面的尷尬，一開始的解決方案就是寫個(gè)腳本，在夜深人靜的時(shí)候，偷偷地重啟釋放一下內(nèi)存。

在性能方面要求最高的我認(rèn)為就是 12306，搞不好是要被全國(guó)人民罵街的。以前在蘇州的時(shí)候，不論是不是節(jié)假日，每次坐火車回洛陽，或者從洛陽去蘇州，都感覺同伴好多啊，怎么這么多人坐火車，不是南下就是北上，不是東進(jìn)就是西出。遇到春運(yùn)的時(shí)候，12306 承載的壓力可想而知有多大，秒殺活動(dòng)壓根沒法和它相提并論。

如果有小伙伴為 12306 工作過，那可以吹一輩子的牛逼了，你比在淘寶雙十一工作過的小伙伴牛逼一萬倍(嗯，我先替你吹一波，據(jù)說 12306 的高峰訪問是 10 億 PV，非常 BT)。

知道了性能調(diào)優(yōu)的重要性后，我來問問小伙伴們，什么時(shí)候介入性能調(diào)優(yōu)會(huì)比較好?

如果你的回答是“越早越好”，那顯然是錯(cuò)誤的答案。

我在之前的文章中提到過軟件開發(fā)的一條原則，就是“Done is better than perfect”，因?yàn)?ldquo;perfect is never done”。性能調(diào)優(yōu)是一項(xiàng)持久戰(zhàn)，很早就開始介入，并不是一件好事。

你想啊，系統(tǒng)第一時(shí)間上線才是最重要的，不然你一邊想著性能調(diào)優(yōu)，一邊疲于開發(fā)進(jìn)度，可能兩者都做不好，反而拖累了系統(tǒng)研發(fā)的進(jìn)度。等你系統(tǒng)上線了，可能用戶已經(jīng)被別的系統(tǒng)搶走了，你永遠(yuǎn)都沒有性能調(diào)優(yōu)的機(jī)會(huì)了。

不要總想著把所有的功能做完善，做完美后再上線，應(yīng)該在產(chǎn)品具有一定的雛形后就立即上線試錯(cuò)，根據(jù)用戶的反饋，根據(jù)市場(chǎng)的需求再去考量是否追加一些其他的功能或者優(yōu)化。

那我再來問問小伙伴，哪些因素會(huì)成為系統(tǒng)的性能瓶頸呢?閉上眼睛，轉(zhuǎn)個(gè)圈，想一想。

• 數(shù)據(jù)庫(kù)：幾乎所有的系統(tǒng)都會(huì)用到數(shù)據(jù)庫(kù)，大量的數(shù)據(jù)庫(kù)讀寫操作會(huì)嚴(yán)重影響到系統(tǒng)的性能，所以數(shù)據(jù)庫(kù)緩存技術(shù) Redis 變得越來越重要。另外，系統(tǒng)運(yùn)行時(shí)間久了之后，數(shù)據(jù)量就會(huì)變得非常大，不僅需要在 SQL 上做很多優(yōu)化，還要在分庫(kù)分表上下足功夫。
• 網(wǎng)絡(luò)：如果你家的網(wǎng)速很慢，那就要去問問運(yùn)營(yíng)商，你家的帶寬多少?；蛘撸辽贆z查一下，你家的網(wǎng)線是百兆的還是千兆的，雖然網(wǎng)線都很短，短到只有貓到路由器那么一小節(jié)。網(wǎng)絡(luò)帶寬如果太小的話，就意味著數(shù)據(jù)傳輸?shù)煤苈?，就像跑車到市區(qū)，搞不好還沒有自行車快。
• 磁盤：我家里的臺(tái)式機(jī)都換成了固態(tài)硬盤，換了之后的速度就比之前普通硬盤的快很多。多說一點(diǎn)，數(shù)據(jù)庫(kù)的讀寫操作就是磁盤 I/O，而 Redis 之所以快，就是因?yàn)?Redis 操作的是內(nèi)存，但 Redis 牛逼的一點(diǎn)在于它不僅可以做緩存，還可以將數(shù)據(jù)持久化到磁盤。
• 內(nèi)存：內(nèi)存的讀寫速度比磁盤快得多，但空間遠(yuǎn)沒有磁盤那么大，一般家用的計(jì)算機(jī)內(nèi)存在 16G 已經(jīng)是很高的配置了。眾所周知，Java 程序是通過 JVM 分配內(nèi)存的，創(chuàng)建的對(duì)象都放在堆內(nèi)存上，操作起來就很快，但如果代碼寫得有問題的話，就很容易造成內(nèi)存溢出。
• CPU：CPU 的計(jì)算速度快到超出人的想象，所以阿爾法狗可以輕松地打敗柯潔。如果，我真的是說如果啊，放在 CPU 還是奔騰的年代，柯潔還是可以輕松打敗阿爾法狗的。如果程序涉及到大量的上下文切換，或者造成 JVM 頻繁的 GC，就很容易長(zhǎng)時(shí)間占用 CPU，導(dǎo)致出現(xiàn)性能問題。

在實(shí)際的工作當(dāng)中，小伙伴們也可以按照上面的順序進(jìn)行性能調(diào)優(yōu)。一開始，不要盲目對(duì)內(nèi)存和 CPU 下手，這個(gè)難度有點(diǎn)大，并且效果不明顯;搞不好，還會(huì)影響到整個(gè)系統(tǒng)的使用。先從數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)和磁盤著手優(yōu)化，很容易看到效果，并且不容易出錯(cuò)。

最后一個(gè)問題，小伙伴們知道系統(tǒng)的性能指標(biāo)嗎?

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

很多年以前，我干過一件很蠢的事。公司有一臺(tái)閑置的云服務(wù)器，是 Windows Server 版的，剛好有一客戶想體驗(yàn)我司的系統(tǒng)，我就沒想那么多，把系統(tǒng)部署到了這臺(tái)云服務(wù)器上。

結(jié)果呢?

首頁打開的速度超級(jí)慢，慢到需要將近一分鐘的時(shí)間。不僅客戶的下巴驚掉了，我自己的也掉了。

為了挽回顏面，我對(duì)首頁相關(guān)的后端和前端做了很多優(yōu)化，后端刻意使用了緩存技術(shù)，減少了 SQL 語句的查詢;前端壓縮了 JavaScript 和 CSS，減少了請(qǐng)求數(shù)，甚至更換了 CDN，使用了圖片懶加載，但收效甚微。

最后靜下心來想了想，同樣的代碼，部署到 Linux 環(huán)境下的那個(gè)系統(tǒng)就很快，就算是第一次打開首頁需要加載資源，響應(yīng)時(shí)間仍然短到無法感知。于是就把 Windows Server 重裝成了 CentOS，效果立竿見影，響應(yīng)時(shí)間短到離譜。

那，一個(gè)系統(tǒng)的性能好不好，響應(yīng)時(shí)間(指系統(tǒng)對(duì)請(qǐng)求作出響應(yīng)的時(shí)間，比如用戶打開首頁)就是最明顯的一個(gè)直觀上的指標(biāo)。對(duì)于游戲來說，響應(yīng)時(shí)間小于 100 毫秒還算不錯(cuò)，響應(yīng)時(shí)間在 1 秒左右勉強(qiáng)接受，如果響應(yīng)時(shí)間達(dá)到 3 秒就沒法玩了。

2)吞吐量

吞吐量(Transaction Per Second)是指系統(tǒng)在單位時(shí)間內(nèi)處理事務(wù)的數(shù)量，一個(gè)事務(wù)可能包含多次請(qǐng)求，它反映出系統(tǒng)承受的壓力。

需要注意的是，TPS 和 QPS 是不一樣的，后者指的是單位時(shí)間內(nèi)請(qǐng)求的數(shù)量，當(dāng)用戶的操作只包含一個(gè)請(qǐng)求接口時(shí)，TPS 和 QPS 沒有區(qū)別。

吞吐量可以細(xì)分為網(wǎng)絡(luò)吞吐量和磁盤吞吐量。前者是指在某個(gè)時(shí)刻，在網(wǎng)絡(luò)中的兩個(gè)節(jié)點(diǎn)之間，提供給網(wǎng)絡(luò)應(yīng)用的剩余帶寬。即在沒有幀丟失的情況下，設(shè)備能夠接受的最大速率。后者是指單位時(shí)間內(nèi)系統(tǒng)能處理的 I/O 請(qǐng)求數(shù)量，I/O 請(qǐng)求通常為讀或?qū)憯?shù)據(jù)操作請(qǐng)求，關(guān)注的是隨機(jī)讀寫性能。

最后來簡(jiǎn)單總結(jié)一下。性能調(diào)優(yōu)非常重要，不僅用戶體驗(yàn)好，系統(tǒng)穩(wěn)定，更能體現(xiàn)出真正優(yōu)秀的編碼水平。我相信所有的小伙伴都能寫出跑的通的代碼，但至于痛不痛快，就需要在性能方面有所研究了。

換句話說，如果你跳槽到一家公司，恰好解決了原有系統(tǒng)的性能瓶頸，那不得了啊，兄弟，你立馬就得到公司重用了!

本文轉(zhuǎn)載自微信公眾號(hào)「沉默王二」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系沉默王二公眾號(hào)。

加油吧，騷年!