記一次性能優(yōu)化，單臺4核8G機器支撐5萬QPS
[導(dǎo)讀]來源：https://segmentfault.com/a/1190000018075241前言這篇文章的主題是記錄一次程序的性能優(yōu)化，在優(yōu)化的過程中遇到的問題，以及如何去解決的。為大家提供一個優(yōu)化的思路，首先要聲明的一點是，我的方式不是唯一的，大家在性能優(yōu)化之路上遇到的問題都絕...
來源：https://segmentfault.com/a/1190000018075241
前言
這篇文章的主題是記錄一次程序的性能優(yōu)化，在優(yōu)化的過程中遇到的問題，以及如何去解決的。
為大家提供一個優(yōu)化的思路，首先要聲明的一點是，我的方式不是唯一的，大家在性能優(yōu)化之路上遇到的問題都絕對不止一個解決方案。
首先大家要明確的一點是，脫離需求談優(yōu)化都是耍流氓。所以，有誰跟你說在 xx 機器上實現(xiàn)了百萬并發(fā)，基本上可以認(rèn)為是不懂裝懂了，單純的并發(fā)數(shù)完全是無意義的。
其次，我們優(yōu)化之前必須要有一個目標(biāo)。需要優(yōu)化到什么程度，沒有明確目標(biāo)的優(yōu)化是不可控的。再然后，我們必須明確的找出性能瓶頸在哪里，而不能漫無目的的一通亂搞。
這個項目是我在上家公司負(fù)責(zé)一個單獨的模塊。本來是集成在主站代碼中的，后來因為并發(fā)太大，為了防止出現(xiàn)問題后拖累主站服務(wù)，所有由我一個人負(fù)責(zé)拆分出來。
對這個模塊的拆分要求是，壓力測試 QPS 不能低于 3 萬，數(shù)據(jù)庫負(fù)責(zé)不能超過 50%，服務(wù)器負(fù)載不能超過 70%，單次請求時長不能超過 70ms，錯誤率不能超過 5%。
環(huán)境的配置如下:?
需求描述如下：
根據(jù)需求，我們知道了有幾個重要的點：
我們可以看到，上述三個重點都存在數(shù)據(jù)庫的操作，不只有讀庫，還有寫庫操作。
從這里我們可以看到，如果不加緩存的話，所有的請求都壓到數(shù)據(jù)庫，勢必會占滿全部連接數(shù)，出現(xiàn)拒絕訪問的錯誤。同時因為 SQL 執(zhí)行過慢，導(dǎo)致請求無法及時返回。
所以，我們首先要做的就是將寫庫操作剝離開來。提升每一次請求響應(yīng)速度，優(yōu)化數(shù)據(jù)庫連接。
整個系統(tǒng)的架構(gòu)圖如下：
然后進行壓測，結(jié)果如下：
很明顯，問題還是出在數(shù)據(jù)庫。
經(jīng)過排查 SQL 語句，查詢到原因就是：找出合適用戶的配置操作時每次請求都要讀取數(shù)據(jù)庫所導(dǎo)致的連接數(shù)被用完。
因為我們的連接數(shù)只有 800，一旦請求過多勢必會導(dǎo)致數(shù)據(jù)庫瓶頸。好了，問題找到了，我們繼續(xù)優(yōu)化。
更新的架構(gòu)如下：
接下來我們再次壓測，結(jié)果如下：
這個問題是困擾我比較久的一個問題。因為我們可以看到，我們?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é)果如下：
雖然有一點提升，但是并沒有實質(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ù)量。默認(rèn)是?180000。我們調(diào)整為6000。然后打開 timewait 快速回收和開啟重用。
完整的參數(shù)優(yōu)化如下:
到此為止，整個服務(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)了問題還不知道怎么分析查找。
前言
這篇文章的主題是記錄一次程序的性能優(yōu)化，在優(yōu)化的過程中遇到的問題，以及如何去解決的。
為大家提供一個優(yōu)化的思路，首先要聲明的一點是，我的方式不是唯一的，大家在性能優(yōu)化之路上遇到的問題都絕對不止一個解決方案。
如何優(yōu)化
首先大家要明確的一點是，脫離需求談優(yōu)化都是耍流氓。所以，有誰跟你說在 xx 機器上實現(xiàn)了百萬并發(fā)，基本上可以認(rèn)為是不懂裝懂了，單純的并發(fā)數(shù)完全是無意義的。
其次，我們優(yōu)化之前必須要有一個目標(biāo)。需要優(yōu)化到什么程度，沒有明確目標(biāo)的優(yōu)化是不可控的。再然后，我們必須明確的找出性能瓶頸在哪里，而不能漫無目的的一通亂搞。
需求描述
這個項目是我在上家公司負(fù)責(zé)一個單獨的模塊。本來是集成在主站代碼中的，后來因為并發(fā)太大，為了防止出現(xiàn)問題后拖累主站服務(wù)，所有由我一個人負(fù)責(zé)拆分出來。
對這個模塊的拆分要求是，壓力測試 QPS 不能低于 3 萬，數(shù)據(jù)庫負(fù)責(zé)不能超過 50%，服務(wù)器負(fù)載不能超過 70%，單次請求時長不能超過 70ms，錯誤率不能超過 5%。
環(huán)境的配置如下:?
- 服務(wù)器：4 核 8G 內(nèi)存，CentOS 7 系統(tǒng)，SSD 硬盤?
- 數(shù)據(jù)庫：MySQL 5.7，最大連接數(shù) 800?
- 緩存：Redis，1G容量。以上環(huán)境都是購買自騰訊云的服務(wù)。
- 壓測工具：Locust，使用騰訊的彈性伸縮實現(xiàn)分布式的壓測。
需求描述如下：
- 用戶進入首頁，從數(shù)據(jù)庫中查詢是否有合適的彈窗配置。
- 如果沒有，則繼續(xù)等待下一次請求、如果有合適的配置，則返回給前端。
- 如果用戶點擊了彈窗，則記錄用戶點擊，并且在配置的時間內(nèi)不再返回配置；
- 如果用戶未點擊，則24小時后繼續(xù)返回本次配置；
- 如果用戶點擊了，但是后續(xù)沒有配置了，則接著等待下一次。
重點分析
根據(jù)需求，我們知道了有幾個重要的點：
- 需要找出合適用戶的彈窗配置，
- 需要記錄用戶下一次返回配置的時間并記錄到數(shù)據(jù)庫中，
- 需要記錄用戶對返回的配置執(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)圖如下：
然后進行壓測，結(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)如下：
接下來我們再次壓測，結(jié)果如下：
- QPS 壓到 2 萬左右的時候就上不去了；
- 服務(wù)器 CPU 在 60%-80% 之間跳動；
- 數(shù)據(jù)庫連接數(shù)為 300 個左右，每秒 TCP 連接數(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 個左右，每秒 TCP 連接數(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ù)量。默認(rèn)是?180000。我們調(diào)整為6000。然后打開 timewait 快速回收和開啟重用。
完整的參數(shù)優(yōu)化如下:
#timewait 的數(shù)量，默認(rèn)是 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é)果顯示：- QPS 5萬，服務(wù)器 CPU 70%；
- 數(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)了問題還不知道怎么分析查找。
下載文檔
