前言

這篇文章的主題是記錄一次Python程序的性能優(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)存，centos7系統(tǒng)，ssd硬盤
數(shù)據(jù)庫(kù)：Mysql5.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)求、如果有合適的配置，則返回給前端。這里開始則有多個(gè)條件分支，如果用戶點(diǎn)擊了彈窗，則記錄用戶點(diǎn)擊，并且在配置的時(shí)間內(nèi)不再返回配置，如果用戶未點(diǎn)擊，則24小時(shí)后繼續(xù)返回本次配置，如果用戶點(diǎn)擊了，但是后續(xù)沒(méi)有配置了，則接著等待下一次。

重點(diǎn)分析

根據(jù)需求，我們知道了有幾個(gè)重要的點(diǎn)，1、需要找出合適用戶的彈窗配置，2、需要記錄用戶下一次返回配置的時(shí)間并記錄到數(shù)據(jù)庫(kù)中，3、需要記錄用戶對(duì)返回的配置執(zhí)行了什么操作并記錄到數(shù)據(jù)庫(kù)中。

調(diào)優(yōu)

我們可以看到，上述三個(gè)重點(diǎn)都存在數(shù)據(jù)庫(kù)的操作，不只有讀庫(kù)，還有寫庫(kù)操作。從這里我們可以看到如果不加緩存的話，所有的請(qǐng)求都?jí)旱綌?shù)據(jù)庫(kù)，勢(shì)必會(huì)占滿全部連接數(shù)，出現(xiàn)拒絕訪問(wèn)的錯(cuò)誤，同時(shí)因?yàn)閟ql執(zhí)行過(guò)慢，導(dǎo)致請(qǐng)求無(wú)法及時(shí)返回。所以，我們首先要做的就是講寫庫(kù)操作剝離開來(lái)，提升每一次請(qǐng)求響應(yīng)速度，優(yōu)化數(shù)據(jù)庫(kù)連接。

將寫庫(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)槲覀兊倪B接數(shù)只有800，一旦請(qǐng)求過(guò)多，勢(shì)必會(huì)導(dǎo)致數(shù)據(jù)庫(kù)瓶頸。好了，問(wèn)題找到了，我們繼續(xù)優(yō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è)左右，每秒tpc連接數(shù)為1.5萬(wàn)左右。

這個(gè)問(wèn)題是困擾我比較久的一個(gè)問(wèn)題，因?yàn)槲覀兛梢钥吹?#xff0c;我們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è)左右，每秒tpc連接數(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，然后打開timewait快速回收，和開啟重用，完整的參數(shù)優(yōu)化如下

#timewait 的數(shù)量，默認(rèn)是 180000。 net.ipv4.tcp_max_tw_buckets = 6000net.ipv4.ip_local_port_range = 1024 65000#啟用 timewait 快速回收。 net.ipv4.tcp_tw_recycle = 1 #開啟重用。允許將 TIME-WAIT sockets 重新用于新的 TCP 連接。 net.ipv4.tcp_tw_reuse = 1

我們?cè)俅螇簻y(cè)，結(jié)果顯示：
QPS5萬(wàn)，服務(wù)器cpu70%,數(shù)據(jù)庫(kù)連接正常，tcp連接正常，響應(yīng)時(shí)間平均為60ms，錯(cuò)誤率為0%。

結(jié)語(yǔ)

到此為止，整個(gè)服務(wù)的開發(fā)、調(diào)優(yōu)、和壓測(cè)就結(jié)束了。回顧這一次調(diào)優(yōu)，得到了很多經(jīng)驗(yàn)，最重要的是，深刻理解了web開發(fā)不是一個(gè)獨(dú)立的個(gè)體，而是網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)、編程語(yǔ)言、操作系統(tǒng)等多門學(xué)科結(jié)合的工程實(shí)踐，這就要求web開發(fā)人員有牢固的基礎(chǔ)知識(shí)，否則出現(xiàn)了問(wèn)題還不知道怎么分析查找。

ps：服務(wù)端開啟了 tcp_tw_recycle 和 tcp_tw_reuse是會(huì)導(dǎo)致一些問(wèn)題的，我們?yōu)榱藘?yōu)化選擇犧牲了一部分，獲得另一部分，這也是我們要明確的，具體的問(wèn)題可以查看耗子叔的文章TCP 的那些事兒（上）

?

閱讀原文

轉(zhuǎn)載于:https://www.cnblogs.com/276815076/p/10394587.html

總結(jié)

以上是生活随笔為你收集整理的记一次性能优化，限制tcp_timewait数量，快速回收和重用的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。