記一次性能優化，單臺 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 開發人員有牢固的基礎知識，否則出現了問題還不知道怎麼分析查找。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/v8_pOYMddk25_Lzq0w4Tfg

猜你喜歡