前言
這篇文章的主題是記錄一次性能優(yōu)化剔猿,在優(yōu)化的過程中遇到的問題,以及如何去解決的嬉荆。為大家提供一個優(yōu)化的思路归敬,首先要聲明的一點是,我的方式不是唯一的鄙早,大家在性能優(yōu)化之路上遇到的問題都絕對不止一個解決方案汪茧。
如何優(yōu)化
首先大家要明確的一點是,脫離需求談優(yōu)化都是耍流氓限番,所以有誰跟你說在xx機器上實現(xiàn)了百萬并發(fā)舱污,基本上可以認為是不懂裝懂了,單純的并發(fā)數(shù)完全是無意義的弥虐。其次扩灯,我們優(yōu)化之前必須要有一個目標,需要優(yōu)化到什么程度霜瘪,沒有明確目標的優(yōu)化是不可控的珠插。再然后,我們必須明確的找出性能瓶頸在哪里粥庄,而不能漫無目的的一通亂搞丧失。
需求描述
這個項目是我在上家公司負責(zé)一個單獨的模塊,本來是集成在主站代碼中的惜互,后來因為并發(fā)太大布讹,為了防止出現(xiàn)問題后拖累主站服務(wù)琳拭,所有由我一個人負責(zé)拆分出來。對這個模塊的拆分要求是描验,壓力測試QPS不能低于3萬白嘁,數(shù)據(jù)庫負載不能超過50%,服務(wù)器負載不能超過70%, 單次請求時長不能超過70ms膘流,錯誤率不能超過5%絮缅。
環(huán)境的配置如下:
服務(wù)器:4核8G內(nèi)存,centos7系統(tǒng)呼股,ssd硬盤
數(shù)據(jù)庫:Mysql5.7耕魄,最大連接數(shù)800
緩存: redis, 1G容量。
以上環(huán)境都是購買自騰訊云的服務(wù)彭谁。
壓測工具:locust吸奴,使用騰訊的彈性伸縮實現(xiàn)分布式的壓測。
需求描述如下:
用戶進入首頁缠局,從數(shù)據(jù)庫中查詢是否有合適的彈窗配置则奥,如果沒有,則繼續(xù)等待下一次請求狭园、如果有合適的配置读处,則返回給前端。這里開始則有多個條件分支唱矛,如果用戶點擊了彈窗罚舱,則記錄用戶點擊,并且在配置的時間內(nèi)不再返回配置绎谦,如果用戶未點擊馆匿,則24小時后繼續(xù)返回本次配置,如果用戶點擊了燥滑,但是后續(xù)沒有配置了,則接著等待下一次阿逃。
重點分析
根據(jù)需求铭拧,我們知道了有幾個重要的點,1恃锉、需要找出合適用戶的彈窗配置搀菩,2、需要記錄用戶下一次返回配置的時間并記錄到數(shù)據(jù)庫中破托,3肪跋、需要記錄用戶對返回的配置執(zhí)行了什么操作并記錄到數(shù)據(jù)庫中。
調(diào)優(yōu)
我們可以看到土砂,上述三個重點都存在數(shù)據(jù)庫的操作州既,不只有讀庫谜洽,還有寫庫操作。從這里我們可以看到如果不加緩存的話吴叶,所有的請求都壓到數(shù)據(jù)庫阐虚,勢必會占滿全部連接數(shù),出現(xiàn)拒絕訪問的錯誤蚌卤,同時因為sql執(zhí)行過慢实束,導(dǎo)致請求無法及時返回。所以逊彭,我們首先要做的就是講寫庫操作剝離開來咸灿,提升每一次請求響應(yīng)速度,優(yōu)化數(shù)據(jù)庫連接侮叮。整個系統(tǒng)的架構(gòu)圖如下:
將寫庫操作放到一個先進先出的消息隊列中來做避矢,為了減少復(fù)雜度,使用了redis的list來做這個消息隊列签赃。
然后進行壓測谷异,結(jié)果如下:
QPS在6000左右502錯誤大幅上升至30%,服務(wù)器cpu在60%-70%之間來回跳動锦聊,數(shù)據(jù)庫連接數(shù)被占滿tcp連接數(shù)為6000左右歹嘹,很明顯,問題還是出在數(shù)據(jù)庫孔庭,經(jīng)過排查sql語句尺上,查詢到原因就是找出合適用戶的配置操作時每次請求都要讀取數(shù)據(jù)庫所導(dǎo)致的連接數(shù)被用完。因為我們的連接數(shù)只有800圆到,一旦請求過多怎抛,勢必會導(dǎo)致數(shù)據(jù)庫瓶頸。好了芽淡,問題找到了马绝,我們繼續(xù)優(yōu)化,更新的架構(gòu)如下
我們將全部的配置都加載到緩存中挣菲,只有在緩存中沒有配置的時候才會去讀取數(shù)據(jù)庫富稻。
接下來我們再次壓測,結(jié)果如下:
QPS壓到2萬左右的時候就上不去了白胀,服務(wù)器cpu在60%-80%之間跳動椭赋,數(shù)據(jù)庫連接數(shù)為300個左右,每秒tpc連接數(shù)為1.5萬左右或杠。
這個問題是困擾我比較久的一個問題哪怔,因為我們可以看到,我們2萬的QPS,但是tcp連接數(shù)卻并沒有達到2萬认境,我猜測胚委,tcp連接數(shù)就是引發(fā)瓶頸的問題,但是因為什么原因所引發(fā)的暫時無法找出來元暴。
這個時候猜測篷扩,既然是無法建立tcp連接,是否有可能是服務(wù)器限制了socket連接數(shù)茉盏,驗證猜測鉴未,我們看一下,在終端輸入ulimit -n命令鸠姨,顯示的結(jié)果為65535铜秆,看到這里,覺得socket連接數(shù)并不是限制我們的原因讶迁,為了驗證猜測连茧,將socket連接數(shù)調(diào)大為100001.
再次進行壓測,結(jié)果如下:
QPS壓到2.2萬左右的時候就上不去了巍糯,服務(wù)器cpu在60%-80%之間跳動啸驯,數(shù)據(jù)庫連接數(shù)為300個左右,每秒tpc連接數(shù)為1.7萬左右祟峦。
雖然有一點提升罚斗,但是并沒有實質(zhì)性的變化,接下來的幾天時間宅楞,我發(fā)現(xiàn)都無法找到優(yōu)化的方案针姿,那幾天確實很難受,找不出來優(yōu)化的方案厌衙,過了幾天距淫,再次將問題梳理了一遍,發(fā)現(xiàn)婶希,雖然socket連接數(shù)足夠榕暇,但是并沒有全部被用上,猜測喻杈,每次請求過后拐揭,tcp連接并沒有立即被釋放,導(dǎo)致socket無法重用奕塑。經(jīng)過查找資料,找到了問題所在家肯,
tcp鏈接在經(jīng)過四次握手結(jié)束連接后并不會立即釋放龄砰,而是處于timewait狀態(tài),會等待一段時間,以防止客戶端后續(xù)的數(shù)據(jù)未被接收换棚。
好了式镐,問題找到了,我們要接著優(yōu)化固蚤,首先想到的就是調(diào)整tcp鏈接結(jié)束后等待時間娘汞,但是linux并沒有提供這一內(nèi)核參數(shù)的調(diào)整,如果要改夕玩,必須要自己重新編譯內(nèi)核你弦,幸好還有另一個參數(shù)net.ipv4.tcp_max_tw_buckets, timewait 的數(shù)量燎孟,默認是 180000禽作。我們調(diào)整為6000,然后打開timewait快速回收揩页,和開啟重用旷偿,完整的參數(shù)優(yōu)化如下
#timewait 的數(shù)量,默認是 180000爆侣。
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.ip_local_port_range = 1024 65000
#啟用 timewait 快速回收萍程。
net.ipv4.tcp_tw_recycle = 1
#開啟重用。允許將 TIME-WAIT sockets 重新用于新的 TCP 連接兔仰。
net.ipv4.tcp_tw_reuse = 1
我們再次壓測茫负,結(jié)果顯示:
QPS5萬,服務(wù)器cpu70%,數(shù)據(jù)庫連接正常斋陪,tcp連接正常朽褪,響應(yīng)時間平均為60ms,錯誤率為0%无虚。
結(jié)語
到此為止缔赠,整個服務(wù)的開發(fā)、調(diào)優(yōu)友题、和壓測就結(jié)束了嗤堰。回顧這一次調(diào)優(yōu)度宦,得到了很多經(jīng)驗踢匣,最重要的是,深刻理解了web開發(fā)不是一個獨立的個體戈抄,而是網(wǎng)絡(luò)离唬、數(shù)據(jù)庫、編程語言划鸽、操作系統(tǒng)等多門學(xué)科結(jié)合的工程實踐输莺,這就要求web開發(fā)人員有牢固的基礎(chǔ)知識戚哎,否則出現(xiàn)了問題還不知道怎么分析查找。