來(lái)源:https://segmentfault.com/a/1190000018075241
前言
這篇文章的主題是記錄一次程序的性能優(yōu)化,在優(yōu)化的過(guò)程中遇到的問(wèn)題套腹,以及如何去解決的窘行。
為大家提供一個(gè)優(yōu)化的思路僧须,首先要聲明的一點(diǎn)是,我的方式不是唯一的紫新,大家在性能優(yōu)化之路上遇到的問(wèn)題都絕對(duì)不止一個(gè)解決方案均蜜。
如何優(yōu)化
首先大家要明確的一點(diǎn)是,脫離需求談優(yōu)化都是耍流氓芒率。所以囤耳,有誰(shuí)跟你說(shuō)在 xx 機(jī)器上實(shí)現(xiàn)了百萬(wàn)并發(fā),基本上可以認(rèn)為是不懂裝懂了敲董,單純的并發(fā)數(shù)完全是無(wú)意義的。
其次慰安,我們優(yōu)化之前必須要有一個(gè)目標(biāo)腋寨。需要優(yōu)化到什么程度,沒(méi)有明確目標(biāo)的優(yōu)化是不可控的化焕。再然后萄窜,我們必須明確的找出性能瓶頸在哪里,而不能漫無(wú)目的的一通亂搞撒桨。
需求描述
這個(gè)項(xiàng)目是我在上家公司負(fù)責(zé)一個(gè)單獨(dú)的模塊查刻。本來(lái)是集成在主站代碼中的,后來(lái)因?yàn)椴l(fā)太大凤类,為了防止出現(xiàn)問(wèn)題后拖累主站服務(wù)穗泵,所有由我一個(gè)人負(fù)責(zé)拆分出來(lái)。
對(duì)這個(gè)模塊的拆分要求是谜疤,壓力測(cè)試 QPS 不能低于 3 萬(wàn)佃延,數(shù)據(jù)庫(kù)負(fù)責(zé)不能超過(guò) 50%,服務(wù)器負(fù)載不能超過(guò) 70%夷磕,單次請(qǐng)求時(shí)長(zhǎng)不能超過(guò) 70ms履肃,錯(cuò)誤率不能超過(guò) 5%。
**環(huán)境的配置如下: **
- 服務(wù)器:4 核 8G 內(nèi)存坐桩,CentOS 7 系統(tǒng)尺棋,SSD 硬盤
- 數(shù)據(jù)庫(kù):MySQL 5.7,最大連接數(shù) 800
- 緩存:Redis绵跷,1G容量膘螟。以上環(huán)境都是購(gòu)買自騰訊云的服務(wù)。
- 壓測(cè)工具:Locust碾局,使用騰訊的彈性伸縮實(shí)現(xiàn)分布式的壓測(cè)萍鲸。
需求描述如下:
- 用戶進(jìn)入首頁(yè),從數(shù)據(jù)庫(kù)中查詢是否有合適的彈窗配置擦俐。
- 如果沒(méi)有脊阴,則繼續(xù)等待下一次請(qǐng)求、如果有合適的配置,則返回給前端嘿期。
這里開(kāi)始則有多個(gè)條件分支:
- 如果用戶點(diǎn)擊了彈窗品擎,則記錄用戶點(diǎn)擊,并且在配置的時(shí)間內(nèi)不再返回配置备徐;
- 如果用戶未點(diǎn)擊萄传,則24小時(shí)后繼續(xù)返回本次配置;
- 如果用戶點(diǎn)擊了蜜猾,但是后續(xù)沒(méi)有配置了秀菱,則接著等待下一次。
重點(diǎn)分析
根據(jù)需求蹭睡,我們知道了有幾個(gè)重要的點(diǎn):
- 需要找出合適用戶的彈窗配置衍菱,
- 需要記錄用戶下一次返回配置的時(shí)間并記錄到數(shù)據(jù)庫(kù)中,
- 需要記錄用戶對(duì)返回的配置執(zhí)行了什么操作并記錄到數(shù)據(jù)庫(kù)中肩豁。
調(diào)優(yōu)
我們可以看到脊串,上述三個(gè)重點(diǎn)都存在數(shù)據(jù)庫(kù)的操作,不只有讀庫(kù)清钥,還有寫(xiě)庫(kù)操作琼锋。從這里我們可以看到,如果不加緩存的話祟昭,所有的請(qǐng)求都?jí)旱綌?shù)據(jù)庫(kù)缕坎,勢(shì)必會(huì)占滿全部連接數(shù),出現(xiàn)拒絕訪問(wèn)的錯(cuò)誤篡悟。同時(shí)因?yàn)?SQL 執(zhí)行過(guò)慢念赶,導(dǎo)致請(qǐng)求無(wú)法及時(shí)返回。所以恰力,我們首先要做的就是將寫(xiě)庫(kù)操作剝離開(kāi)來(lái)叉谜。提升每一次請(qǐng)求響應(yīng)速度,優(yōu)化數(shù)據(jù)庫(kù)連接踩萎。整個(gè)系統(tǒng)的架構(gòu)圖如下:將寫(xiě)庫(kù)操作放到一個(gè)先進(jìn)先出的消息隊(duì)列中來(lái)做停局。為了減少?gòu)?fù)雜度,使用了 Redis 的 list 來(lái)做這個(gè)消息隊(duì)列香府。
然后進(jìn)行壓測(cè)董栽,結(jié)果如下:
- QPS 在 6000 左右 502 錯(cuò)誤大幅上升至 30%;
- 服務(wù)器 CPU 在 60%-70% 之間來(lái)回跳動(dòng)企孩;
- 數(shù)據(jù)庫(kù)連接數(shù)被占滿 TCP 連接數(shù)為 6000 左右锭碳。
很明顯,問(wèn)題還是出在數(shù)據(jù)庫(kù)勿璃。經(jīng)過(guò)排查 SQL 語(yǔ)句擒抛,查詢到原因就是:找出合適用戶的配置操作時(shí)每次請(qǐng)求都要讀取數(shù)據(jù)庫(kù)所導(dǎo)致的連接數(shù)被用完推汽。因?yàn)槲覀兊?strong>連接數(shù)只有 800,一旦請(qǐng)求過(guò)多勢(shì)必會(huì)導(dǎo)致數(shù)據(jù)庫(kù)瓶頸歧沪。好了歹撒,問(wèn)題找到了,我們繼續(xù)優(yōu)化诊胞。更新的架構(gòu)如下:
我們將全部的配置都加載到緩存中暖夭,只有在緩存中沒(méi)有配置的時(shí)候才會(huì)去讀取數(shù)據(jù)庫(kù)。
接下來(lái)我們?cè)俅螇簻y(cè)撵孤,結(jié)果如下:
- QPS 壓到 2 萬(wàn)左右的時(shí)候就上不去了迈着;
- 服務(wù)器 CPU 在 60%-80% 之間跳動(dòng);
- 數(shù)據(jù)庫(kù)連接數(shù)為 300 個(gè)左右邪码,每秒 TCP 連接數(shù)為 1.5 萬(wàn)左右裕菠。
這個(gè)問(wèn)題是困擾我比較久的一個(gè)問(wèn)題。因?yàn)槲覀兛梢钥吹较佳铮覀?2 萬(wàn)的 QPS糕韧,但是 TCP 連接數(shù)卻并沒(méi)有達(dá)到 2 萬(wàn)枫振。我猜測(cè)喻圃,TCP 連接數(shù)就是引發(fā)瓶頸的問(wèn)題,但是因?yàn)槭裁丛蛩l(fā)的暫時(shí)無(wú)法找出來(lái)粪滤。這個(gè)時(shí)候猜測(cè)斧拍,既然是無(wú)法建立 TCP 連接,是否有可能是服務(wù)器限制了 socket 連接數(shù)杖小。驗(yàn)證猜測(cè)肆汹,我們看一下,在終端輸入 ulimit -n 命令予权,顯示的結(jié)果為 65535昂勉。看到這里扫腺,覺(jué)得 socket 連接數(shù)并不是限制我們的原因岗照,為了驗(yàn)證猜測(cè),將 socket 連接數(shù)調(diào)大為100001笆环。再次進(jìn)行壓測(cè)攒至,結(jié)果如下:
- QPS 壓到 2.2 萬(wàn)左右的時(shí)候就上不去了;
- 服務(wù)器 CPU 在 60%-80% 之間跳動(dòng)躁劣;
- 數(shù)據(jù)庫(kù)連接數(shù)為 300 個(gè)左右迫吐,每秒 TCP 連接數(shù)為 1.7 萬(wàn)左右。
雖然有一點(diǎn)提升账忘,但是并沒(méi)有實(shí)質(zhì)性的變化志膀。接下來(lái)的幾天時(shí)間熙宇,我發(fā)現(xiàn)都無(wú)法找到優(yōu)化的方案。那幾天確實(shí)很難受梧却,找不出來(lái)優(yōu)化的方案奇颠,過(guò)了幾天再次將問(wèn)題梳理了一遍,發(fā)現(xiàn)雖然 socket 連接數(shù)足夠放航,但是并沒(méi)有全部被用上烈拒。猜測(cè)每次請(qǐng)求過(guò)后,TCP 連接并沒(méi)有立即被釋放广鳍,導(dǎo)致 socket 無(wú)法重用荆几。經(jīng)過(guò)查找資料,找到了問(wèn)題所在:TCP 鏈接在經(jīng)過(guò)四次握手結(jié)束連接后并不會(huì)立即釋放赊时,而是處于 timewait 狀態(tài)吨铸。會(huì)等待一段時(shí)間,以防止客戶端后續(xù)的數(shù)據(jù)未被接收祖秒。好了诞吱,問(wèn)題找到了,我們要接著優(yōu)化竭缝。首先想到的就是調(diào)整 TCP 鏈接結(jié)束后等待時(shí)間房维。但是 Linux并沒(méi)有提供這一內(nèi)核參數(shù)的調(diào)整,如果要改必須要自己重新編譯內(nèi)核抬纸。幸好還有另一個(gè)參數(shù)net.ipv4.tcp_max_tw_buckets咙俩, timewait 的數(shù)量。默認(rèn)是 180000湿故。我們調(diào)整為6000阿趁。然后打開(kāi) timewait 快速回收和開(kāi)啟重用。完整的參數(shù)優(yōu)化如下:
#timewait 的數(shù)量坛猪,默認(rèn)是 180000脖阵。
<pre data-tool="mdnice編輯器" style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important; color: rgb(51, 51, 51); font-size: 17px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: 0.544px; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial; background-color: rgb(255, 255, 255); white-space: normal; text-align: left;">我們?cè)俅螇簻y(cè),結(jié)果顯示:
</pre>
- QPS 5萬(wàn)墅茉,服務(wù)器 CPU 70%命黔;
- 數(shù)據(jù)庫(kù)連接正常,TCP 連接正常躁锁;
- 響應(yīng)時(shí)間平均為 60ms纷铣,錯(cuò)誤率為 0%。
結(jié)語(yǔ)
到此為止战转,整個(gè)服務(wù)的開(kāi)發(fā)搜立、調(diào)優(yōu)、和壓測(cè)就結(jié)束了槐秧∽挠唬回顧這一次調(diào)優(yōu)忧设,得到了很多經(jīng)驗(yàn)。最重要的是颠通,深刻理解了Web 開(kāi)發(fā)不是一個(gè)獨(dú)立的個(gè)體址晕,而是網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)顿锰、編程語(yǔ)言谨垃、操作系統(tǒng)等多門學(xué)科結(jié)合的工程實(shí)踐。這就要求 Web 開(kāi)發(fā)人員有牢固的基礎(chǔ)知識(shí)硼控,否則出現(xiàn)了問(wèn)題還不知道怎么分析查找刘陶。