歡迎光臨
每天分享高質量文章

記一次性能優化,單台 4 核 8G 機器支撐 5 萬 QPS

前言

這篇文章的主題是記錄一次Python程式的性能優化,在優化的過程中遇到的問題,以及如何去解決的。為大家提供一個優化的思路,首先要宣告的一點是,我的方式不是唯一的,大家在性能優化之路上遇到的問題都絕對不止一個解決方案。

如何優化

首先大家要明確的一點是,脫離需求談優化都是耍流氓,所以有誰跟你說在xx機器上實現了百萬併發,基本上可以認為是不懂裝懂了,單純的併發數完全是無意義的。其次,我們優化之前必須要有一個標的,需要優化到什麼程度,沒有明確標的的優化是不可控的。再然後,我們必須明確的找出性能瓶頸在哪裡,而不能漫無目的的一通亂搞。

需求描述

這個專案是我在上家公司負責一個單獨的模塊,本來是集成在主站代碼中的,後來因為併發太大,為了防止出現問題後拖累主站服務,所有由我一個人負責拆分出來。對這個模塊的拆分要求是,壓力測試QPS不能低於3萬,資料庫負不能超過50%,服務器負載不能超過70%, 單次請求時長不能超過70ms,錯誤率不能超過5%。

環境的配置如下:
服務器:4核8G記憶體,centos7系統,ssd硬碟
資料庫:Mysql5.7,最大連接數800
快取: redis, 1G容量。
以上環境都是購買自騰訊雲的服務。
壓測工具:locust,使用騰訊的彈性伸縮實現分佈式的壓測。

需求描述如下:
用戶進入首頁,從資料庫中查詢是否有合適的彈窗配置,如果沒有,則繼續等待下一次請求、如果有合適的配置,則傳回給前端。這裡開始則有多個條件分支,如果用戶點擊了彈窗,則記錄用戶點擊,並且在配置的時間內不再傳回配置,如果用戶未點擊,則24小時後繼續傳回本次配置,如果用戶點擊了,但是後續沒有配置了,則接著等待下一次。

重點分析

根據需求,我們知道了有幾個重要的點,1、需要找出合適用戶的彈窗配置,2、需要記錄用戶下一次傳回配置的時間並記錄到資料庫中,3、需要記錄用戶對傳回的配置執行了什麼操作並記錄到資料庫中。

調優

我們可以看到,上述三個重點都存在資料庫的操作,不只有讀庫,還有寫庫操作。從這裡我們可以看到如果不加快取的話,所有的請求都壓到資料庫,勢必會占滿全部連接數,出現拒絕訪問的錯誤,同時因為sql執行過慢,導致請求無法及時傳回。所以,我們首先要做的就是講寫庫操作剝離開來,提升每一次請求響應速度,優化資料庫連接。整個系統的架構圖如下:

將寫庫操作放到一個先進先出的訊息佇列中來做,為了減少複雜度,使用了redis的list來做這個訊息佇列。

然後進行壓測,結果如下:

QPS在6000左右502錯誤大幅上升至30%,服務器cpu在60%-70%之間來回跳動,資料庫連接數被占滿tcp連接數為6000左右,很明顯,問題還是出在資料庫,經過排查sql陳述句,查詢到原因就是找出合適用戶的配置操作時每次請求都要讀取資料庫所導致的連接數被用完。因為我們的連接數只有800,一旦請求過多,勢必會導致資料庫瓶頸。好了,問題找到了,我們繼續優化,更新的架構如下

我們將全部的配置都加載到快取中,只有在快取中沒有配置的時候才會去讀取資料庫。

接下來我們再次壓測,結果如下:
QPS壓到2萬左右的時候就上不去了,服務器cpu在60%-80%之間跳動,資料庫連接數為300個左右,每秒tpc連接數為1.5萬左右。

這個問題是困擾我比較久的一個問題,因為我們可以看到,我們2萬的QPS,但是tcp連接數卻並沒有達到2萬,我猜測,tcp連接數就是引發瓶頸的問題,但是因為什麼原因所引發的暫時無法找出來。

這個時候猜測,既然是無法建立tcp連接,是否有可能是服務器限制了socket連接數,驗證猜測,我們看一下,在終端輸入ulimit -n命令,顯示的結果為65535,看到這裡,覺得socket連接數並不是限制我們的原因,為了驗證猜測,將socket連接數調大為100001.

再次進行壓測,結果如下:

QPS壓到2.2萬左右的時候就上不去了,服務器cpu在60%-80%之間跳動,資料庫連接數為300個左右,每秒tpc連接數為1.7萬左右。

雖然有一點提升,但是並沒有實質性的變化,接下來的幾天時間,我發現都無法找到優化的方案,那幾天確實很難受,找不出來優化的方案,過了幾天,再次將問題梳理了一遍,發現,雖然socket連接數足夠,但是並沒有全部被用上,猜測,每次請求過後,tcp連接並沒有立即被釋放,導致socket無法重用。經過查找資料,找到了問題所在,

tcp鏈接在經過四次握手結束連接後並不會立即釋放,而是處於timewait狀態,會等待一段時間,以防止客戶端後續的資料未被接收。

好了,問題找到了,我們要接著優化,首先想到的就是調整tcp鏈接結束後等待時間,但是linux並沒有提供這一內核引數的調整,如果要改,必須要自己重新編譯內核,幸好還有另一個引數net.ipv4.tcp_max_tw_buckets, timewait 的數量,預設是 180000。我們調整為6000,然後打開timewait快速回收,和開啟重用,完整的引數優化如下

#timewait 的數量,預設是 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

我們再次壓測,結果顯示:
QPS5萬,服務器cpu70%,資料庫連接正常,tcp連接正常,響應時間平均為60ms,錯誤率為0%。

結語

到此為止,整個服務的開發、調優、和壓測就結束了。回顧這一次調優,得到了很多經驗,最重要的是,深刻理解了web開發不是一個獨立的個體,而是網絡、資料庫、編程語言、操作系統等多門學科結合的工程實踐,這就要求web開發人員有牢固的基礎知識,否則出現了問題還不知道怎麼分析查找。

ps:服務端開啟了 tcp_tw_recycle 和 tcp_tw_reuse是會導致一些問題的,我們為了優化選擇犧牲了一部分,獲得另一部分,這也是我們要明確的,具體的問題可以查看耗子叔的文章TCP 的那些事兒(上)

 

(完)

    赞(0)

    分享創造快樂