1. 項目概述為什么我們需要ab命令在網(wǎng)站開發(fā)和運維的日常工作中性能始終是懸在頭頂?shù)倪_摩克利斯之劍。一個新功能上線一個促銷活動開啟最怕的就是服務(wù)器在流量洪峰面前“躺平”。作為一線工程師我們手里得有趁手的“壓力測試”工具來模擬真實用戶訪問提前發(fā)現(xiàn)瓶頸。ApacheBench也就是我們常說的ab命令就是這樣一個簡單、直接、高效的瑞士軍刀。它沒有復(fù)雜的圖形界面不依賴龐大的測試平臺僅僅通過一行命令就能告訴你服務(wù)器在并發(fā)請求下的表現(xiàn)每秒能處理多少請求QPS平均響應(yīng)時間是多少有多少請求失敗了。這種“開箱即用”的特性讓它成為Linux環(huán)境下進行快速、初步性能評估的首選工具。無論是開發(fā)者在本地驗證接口性能還是運維同學(xué)在生產(chǎn)環(huán)境變更前做一輪基準(zhǔn)測試ab都能在幾分鐘內(nèi)給出關(guān)鍵數(shù)據(jù)。今天我們就來徹底拆解這個工具從安裝到實戰(zhàn)從參數(shù)解讀到結(jié)果分析讓你不僅能“跑”起來更能“看懂”和“用好”它。2. ab命令核心原理與安裝部署2.1 ab命令的工作原理淺析ab本質(zhì)上是一個用于對HTTP/HTTPS服務(wù)器進行基準(zhǔn)測試的命令行工具。它的工作模式非常純粹模擬多個并發(fā)用戶向指定的URL發(fā)送大量HTTP請求并統(tǒng)計服務(wù)器處理這些請求所花費的時間。其核心工作流程可以概括為單線程、多連接。ab本身是一個單進程程序但它會創(chuàng)建多個并發(fā)的“客戶端”通過操作系統(tǒng)套接字實現(xiàn)這些客戶端同時向服務(wù)器發(fā)起請求。它主要測量的是服務(wù)器的網(wǎng)絡(luò)處理能力和請求處理吞吐量而不是客戶端的負(fù)載生成能力。這意味著ab運行所在的測試機性能不能太差否則可能成為瓶頸無法給服務(wù)器施加足夠的壓力。一個常見的誤解是認(rèn)為ab會模擬復(fù)雜的用戶行為比如點擊鏈接、填寫表單。實際上它只做一件事重復(fù)請求同一個URL。這對于測試API接口、靜態(tài)頁面或簡單的動態(tài)頁面如首頁的極限性能非常有效。如果你想測試包含登錄狀態(tài)Session、復(fù)雜業(yè)務(wù)流程的場景ab就顯得力不從心了這時需要考慮 JMeter、Locust 等更高級的工具。但對于快速回答“這個接口在100個并發(fā)下響應(yīng)時間是多少”這類問題ab的效率無與倫比。2.2 在不同Linux發(fā)行版上安裝abab工具通常作為 Apache HTTP Server 工具包的一部分提供包名通常是apache2-utils(Debian/Ubuntu) 或httpd-tools(RHEL/CentOS/Fedora)。安裝非常簡單。在 Debian/Ubuntu 及其衍生系統(tǒng)上sudo apt update sudo apt install apache2-utils -y安裝完成后可以通過ab -V來查看版本信息確認(rèn)安裝成功。在 RHEL/CentOS/Fedora 及其衍生系統(tǒng)上# 對于 CentOS 7/RHEL 7 sudo yum install httpd-tools -y # 對于 CentOS 8/RHEL 8/Fedora sudo dnf install httpd-tools -y在 macOS 上如果你使用 Homebrew可以很方便地安裝brew install apache-httpd # 安裝后ab命令通常位于 /usr/local/bin/ab注意在某些極簡的Docker鏡像或云服務(wù)器模板中可能沒有預(yù)裝。按照上述命令安裝即可。另外請確保測試機本身有足夠的可用端口和網(wǎng)絡(luò)帶寬避免因本地資源限制影響測試結(jié)果。安裝完成后一個簡單的ab -n 10 -c 2 http://localhost/命令就可以開始你的第一次測試了。其中-n 10表示總請求數(shù)為10-c 2表示并發(fā)數(shù)為2。3. 命令參數(shù)深度解析與實戰(zhàn)場景ab的命令行參數(shù)是其強大功能的體現(xiàn)。理解每個參數(shù)的含義是設(shè)計有效壓力測試場景的關(guān)鍵。下面我們分類詳解最常用和最重要的參數(shù)。3.1 基礎(chǔ)負(fù)載參數(shù)定義測試的“量”與“形”這是構(gòu)建測試場景的骨架決定了壓力的大小和模式。-n requests總請求數(shù)。這是測試的停止條件。例如-n 1000表示總共發(fā)送1000個請求后結(jié)束測試。設(shè)置一個足夠大的數(shù)可以讓測試持續(xù)一段時間得到更穩(wěn)定的統(tǒng)計結(jié)果。對于快速驗證可以設(shè)小一點如100對于正式基準(zhǔn)測試建議至少5000以上。-c concurrency并發(fā)用戶數(shù)。這是模擬的同時向服務(wù)器發(fā)起請求的客戶端數(shù)量。這是壓力測試的核心參數(shù)直接決定了服務(wù)器的并發(fā)負(fù)載。-c 10表示模擬10個用戶同時操作。這個值需要根據(jù)你服務(wù)器的預(yù)估并發(fā)量來設(shè)置可以從一個較小的值如10開始逐步增加觀察性能拐點。-t timelimit最大測試時間秒。當(dāng)測試時間達到這個限制無論是否完成-n指定的請求數(shù)測試都會停止。例如-t 30表示測試最多運行30秒。這個參數(shù)在你想進行“持續(xù)一段時間”的壓力測試時非常有用比如想觀察服務(wù)器在長時間壓力下的穩(wěn)定性可以和-n參數(shù)二選一使用。實戰(zhàn)場景選擇容量規(guī)劃測試使用-n和-c。例如-n 50000 -c 100發(fā)送5萬請求并發(fā)100看總耗時和QPS。穩(wěn)定性/耐力測試使用-t和-c。例如-t 600 -c 50用50并發(fā)持續(xù)壓測10分鐘觀察過程中響應(yīng)時間、錯誤率是否有波動。3.2 請求定制參數(shù)模擬更真實的請求默認(rèn)情況下ab發(fā)送的是簡單的 GET 請求。但現(xiàn)實中的請求要復(fù)雜得多。-m method指定HTTP方法。默認(rèn)是GET你可以設(shè)置為-m POST、-m PUT等。-p postfile當(dāng)使用POST方法時包含POST數(shù)據(jù)的文件路徑。文件內(nèi)容通常是表單數(shù)據(jù)如useradminpasswd123或JSON字符串。這是測試API接口的關(guān)鍵參數(shù)。-T content-type設(shè)置POST/PUT數(shù)據(jù)時的Content-Type頭。例如發(fā)送JSON數(shù)據(jù)時必須設(shè)置為-T application/json。-H custom-header添加自定義的HTTP頭。可以重復(fù)使用此參數(shù)添加多個頭。這在測試需要認(rèn)證Authorization頭、特定客戶端標(biāo)識或處理CORS時必不可少。ab -n 100 -c 10 -H “Authorization: Bearer xxxxxxxx” -H “User-Agent: MyTestClient” http://api.example.com/v1/resource-C cookie-namevalue為請求附加Cookie?？梢灾貜?fù)使用以添加多個Cookie。用于測試需要會話狀態(tài)的頁面。-k啟用HTTP KeepAlive持久連接。這會讓ab復(fù)用TCP連接來發(fā)送多個請求而不是為每個請求新建連接。這能大幅減少TCP握手和慢啟動的開銷更貼近現(xiàn)代瀏覽器或客戶端的真實行為測出的QPS通常會高很多。在進行性能對比時務(wù)必統(tǒng)一此參數(shù)的設(shè)置。實戰(zhàn)示例測試一個登錄API假設(shè)我們有一個登錄接口http://api.example.com/login接受JSON格式的POST請求。創(chuàng)建一個文件post_data.json內(nèi)容如下{username: testuser, password: testpass}執(zhí)行命令ab -n 1000 -c 50 -p post_data.json -T ‘a(chǎn)pplication/json’ -H “Accept: application/json” http://api.example.com/login這個命令會以50的并發(fā)向登錄接口發(fā)送1000個包含JSON體的POST請求。3.3 輸出與調(diào)試參數(shù)獲取更詳細(xì)的信息這些參數(shù)幫助你更好地理解測試過程和結(jié)果。-v verbosity設(shè)置詳細(xì)級別。-v 2會打印出每個請求的響應(yīng)頭信息-v 3會打印響應(yīng)體-v 4會打印更多調(diào)試信息。在排查“為什么請求失敗了”時非常有用但輸出會非常冗長不建議在正式壓測時使用高等級。-w將結(jié)果以HTML表格形式輸出?？梢詫⑤敵鲋囟ㄏ虻轿募缓笤跒g覽器中打開查看格式更友好。ab -n 100 -c 10 -w http://localhost/ result.html-X proxy[:port]通過代理服務(wù)器發(fā)送請求。-V顯示版本號并退出。實操心得參數(shù)組合的常見陷阱-n和-t同時使用ab會以先達到的條件為準(zhǔn)停止測試。如果你設(shè)置了-n 10000 -t 10可能10秒內(nèi)只完成了2000個請求測試就停止了總請求數(shù)并非10000。POST數(shù)據(jù)文件格式確保-p指定的文件內(nèi)容格式與-T指定的Content-Type匹配。如果是application/x-www-form-urlencoded文件內(nèi)容應(yīng)是key1value1key2value2如果是application/json則應(yīng)是標(biāo)準(zhǔn)的JSON格式。Cookie和Header的覆蓋通過-H設(shè)置的Header會覆蓋ab內(nèi)部生成的一些默認(rèn)頭如User-Agent。如果你需要保留默認(rèn)頭并添加新的需要顯式地一起設(shè)置。4. 測試結(jié)果報告全方位解讀執(zhí)行完ab命令后屏幕上會輸出一份詳細(xì)的報告。這份報告是性能分析的依據(jù)每一個數(shù)據(jù)都有其特定含義。我們以一個典型的輸出為例分段解讀。假設(shè)我們執(zhí)行了ab -n 1000 -c 100 http://demo.example.com/得到如下結(jié)果數(shù)據(jù)為示例This is ApacheBench, Version 2.3 $Revision: 1879490 $ Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking demo.example.com (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: nginx/1.18.0 # 目標(biāo)服務(wù)器軟件 Server Hostname: demo.example.com Server Port: 80 Document Path: / Document Length: 15243 bytes # 單個響應(yīng)體的大小 Concurrency Level: 100 # 并發(fā)數(shù) Time taken for tests: 2.347 seconds # 整個測試持續(xù)的總時間 Complete requests: 1000 # 成功的請求數(shù) Failed requests: 15 # 失敗的請求數(shù) (Connect: 0, Receive: 0, Length: 15, Exceptions: 0) # 失敗分類 Non-2xx responses: 15 # 非2xx狀態(tài)碼的響應(yīng)數(shù) Total transferred: 15423000 bytes # 所有響應(yīng)數(shù)據(jù)的總大小包括頭信息 HTML transferred: 15243000 bytes # 所有響應(yīng)體中HTML內(nèi)容的總大小 Requests per second: 426.08 [#/sec] (mean) # 核心指標(biāo)每秒請求數(shù)QPS Time per request: 234.700 [ms] (mean) # 核心指標(biāo)每個請求的平均耗時用戶視角 Time per request: 2.347 [ms] (mean, across all concurrent requests) # 核心指標(biāo)服務(wù)器平均處理一個請求的耗時 Transfer rate: 6417.00 [Kbytes/sec] received # 網(wǎng)絡(luò)吞吐量 Connection Times (ms) min mean[/-sd] median max Connect: 0 1 1.2 0 12 Processing: 20 233 45.6 225 412 Waiting: 18 230 45.1 222 410 Total: 20 234 45.7 226 412 Percentage of the requests served within a certain time (ms) 50% 226 # 中位數(shù)響應(yīng)時間 66% 245 75% 256 80% 263 90% 281 95% 302 98% 345 99% 367 100% 412 (longest request) # 最慢的請求耗時4.1 核心性能指標(biāo)解讀這是報告中最需要關(guān)注的部分直接反映了服務(wù)器的性能水平。Requests per second (QPS)每秒請求數(shù)這是衡量服務(wù)器吞吐量的黃金指標(biāo)。示例中426.08 [#/sec]表示服務(wù)器平均每秒能處理426個請求。這個值越高越好。在對比測試時例如優(yōu)化前后這是首要關(guān)注的指標(biāo)。Time per request (mean)這里有兩行容易混淆。第一行 (234.700 [ms] (mean))這是從單個用戶模擬客戶端視角看到的平均請求耗時。計算公式是總測試時間 * 并發(fā)數(shù) / 成功請求數(shù)。即2.347s * 100 / 1000 ≈ 0.2347s。它代表了用戶感受到的延遲。第二行 (2.347 [ms] (mean, across all concurrent requests))這是服務(wù)器平均處理每個請求所花費的時間。計算公式是總測試時間 / 成功請求數(shù)。即2.347s / 1000 ≈ 0.002347s。這個值更接近服務(wù)器處理能力的理論值。這兩個值的關(guān)系是第一行 第二行 * 并發(fā)數(shù)。Failed requests / Non-2xx responses失敗請求數(shù)和非2xx響應(yīng)數(shù)。任何非零值都需要警惕。示例中失敗了15個且都是因為Length失敗響應(yīng)體長度與第一個成功請求的長度不一致或返回了非2xx狀態(tài)碼。這可能是服務(wù)器在高壓下出現(xiàn)了錯誤如5xx或者響應(yīng)內(nèi)容不一致。必須結(jié)合日志排查原因。4.2 連接時間與百分比分布這部分?jǐn)?shù)據(jù)揭示了請求耗時的分布情況對于發(fā)現(xiàn)長尾延遲至關(guān)重要。Connection Times分解了請求各階段的時間。Connect建立TCP連接的時間。如果這個值很大可能是網(wǎng)絡(luò)問題或服務(wù)器連接池滿了。Processing從發(fā)送完請求到接收完響應(yīng)的時間可以近似理解為服務(wù)器的處理時間。Waiting從發(fā)送完請求到接收到響應(yīng)第一個字節(jié)的時間TTFB - Time To First Byte。這個值很關(guān)鍵反映了服務(wù)器的即時響應(yīng)能力。Total整個請求的總耗時Connect Processing。mean[/-sd]表示平均值和標(biāo)準(zhǔn)差。標(biāo)準(zhǔn)差大說明響應(yīng)時間波動大性能不穩(wěn)定。Percentage of the requests served within a certain time響應(yīng)時間百分比分布。這是評估服務(wù)穩(wěn)定性和用戶體驗的關(guān)鍵。50%中位數(shù)一半的請求在這個時間內(nèi)完成。示例是226ms。90%/95%/99%90%/95%/99%的請求在這個時間內(nèi)完成。我們尤其關(guān)注90%或95%線。示例中90%的請求在281ms內(nèi)完成但最慢的請求達到了412ms。如果99%線367ms比中位數(shù)226ms高很多說明存在一些慢請求影響了部分用戶的體驗需要優(yōu)化。在SLA服務(wù)等級協(xié)議中通常會承諾“95%的請求響應(yīng)時間低于X毫秒”。4.3 網(wǎng)絡(luò)與資源指標(biāo)Transfer rate網(wǎng)絡(luò)傳輸速率。示例6417.00 [Kbytes/sec]表示平均每秒從服務(wù)器接收了約6.4MB數(shù)據(jù)。這個值可以幫助判斷網(wǎng)絡(luò)帶寬是否成為瓶頸。如果這個值接近測試機或服務(wù)器的網(wǎng)絡(luò)帶寬上限那么性能瓶頸可能在網(wǎng)絡(luò)I/O上。Document Length / Total transferred反映了響應(yīng)數(shù)據(jù)的大小。過大的響應(yīng)體會消耗更多網(wǎng)絡(luò)帶寬和處理時間。分析心法如何從報告中發(fā)現(xiàn)問題看失敗率失敗率 0% 是最高優(yōu)先級問題。立刻檢查服務(wù)器日志看是超時、5xx錯誤還是應(yīng)用層錯誤?？碤PS對比歷史基準(zhǔn)值或預(yù)期值。如果QPS過低說明吞吐量不足。看響應(yīng)時間分布如果90%/95%線比50%線高很多例如3倍以上說明服務(wù)有“長尾”問題部分請求很慢?？赡茉虬〝?shù)據(jù)庫慢查詢、緩存失效、外部依賴服務(wù)不穩(wěn)定、垃圾回收GC等。看連接時間如果Connect或Waiting時間異常高可能指向網(wǎng)絡(luò)問題、服務(wù)器負(fù)載過高導(dǎo)致無法快速接受連接或開始處理。結(jié)合監(jiān)控在壓測時同時使用top,vmstat,iostat等命令監(jiān)控服務(wù)器的CPU、內(nèi)存、磁盤I/O和網(wǎng)絡(luò)流量。如果QPS上不去但CPU已跑滿說明是計算瓶頸如果CPU空閑但QPS低可能是I/O磁盤/網(wǎng)絡(luò)或外部服務(wù)瓶頸。5. 高級實戰(zhàn)技巧與腳本化壓測掌握了基礎(chǔ)用法和報告解讀我們可以進行更貼近真實場景的復(fù)雜測試。5.1 模擬混合場景與參數(shù)化請求ab本身一次只能測試一個固定URL。但我們可以通過Shell腳本組合多個ab命令來模擬簡單的混合場景。例如一個電商頁面70%的請求是瀏覽商品GET /product/{id}30%的請求是加入購物車POST /cart。#!/bin/bash # simulate_mixed_traffic.sh BASE_URL“http://localhost:8080” CONCURRENCY50 TOTAL_REQUESTS1000 # 計算不同場景的請求數(shù) PRODUCT_REQS$((TOTAL_REQUESTS * 70 / 100)) CART_REQS$((TOTAL_REQUESTS * 30 / 100)) echo “ 開始壓測商品頁 (70%) ” ab -n $PRODUCT_REQS -c $CONCURRENCY “${BASE_URL}/product/123” result_product.txt 21 echo “ 開始壓測購物車接口 (30%) ” # 假設(shè)購物車接口需要POST一個JSON body cat cart_data.json EOF {“productId”: 123, “quantity”: 1} EOF ab -n $CART_REQS -c $CONCURRENCY -p cart_data.json -T ‘a(chǎn)pplication/json’ -m POST “${BASE_URL}/cart” result_cart.txt 21 # 等待所有后臺任務(wù)完成 wait echo “ 壓測完成 ” echo “商品頁結(jié)果見 result_product.txt” echo “購物車結(jié)果見 result_cart.txt”這個腳本同時啟動了兩個ab進程分別壓測不同的接口。需要注意的是這樣測試的是兩個獨立的流它們會競爭測試機的網(wǎng)絡(luò)和端口資源并非嚴(yán)格的比例控制但可以作為一個近似的混合負(fù)載測試。對于URL路徑中的變量如/product/{id}ab無法直接參數(shù)化。一個變通的方法是準(zhǔn)備一個包含多個URL的文件然后寫一個循環(huán)但這樣每個ab進程只測一個URL效率較低。對于復(fù)雜的參數(shù)化測試建議轉(zhuǎn)向 JMeter 或 Locust。5.2 持續(xù)壓力與梯度加壓測試我們經(jīng)常需要觀察系統(tǒng)在持續(xù)壓力下的表現(xiàn)或者逐步增加壓力找到性能拐點。持續(xù)壓力測試穩(wěn)定性測試# 持續(xù)壓測5分鐘并發(fā)100 ab -t 300 -c 100 -k http://localhost/api/health使用-t參數(shù)和-k啟用長連接模擬穩(wěn)定持續(xù)的負(fù)載。梯度加壓測試尋找瓶頸點#!/bin/bash # step_load_test.sh URL“http://localhost:8080/api/data” DURATION60 # 每個梯度持續(xù)60秒 for concurrent in 10 30 50 80 100 150 200 do echo “” echo “正在測試并發(fā)數(shù): $concurrent” echo “” # 每個梯度壓測60秒輸出結(jié)果到獨立文件 ab -t $DURATION -c $concurrent -k “$URL” “result_${concurrent}.txt” 21 # 簡單提取關(guān)鍵指標(biāo) grep “Requests per second:” “result_${concurrent}.txt” grep “Time per request:” “result_${concurrent}.txt” | head -1 grep “Failed requests:” “result_${concurrent}.txt” echo “” # 可選每個梯度之間休息10秒讓系統(tǒng)恢復(fù) sleep 10 done運行這個腳本你會看到隨著并發(fā)數(shù)增加QPS和響應(yīng)時間的變化。當(dāng)并發(fā)數(shù)增加到某個點后QPS不再增長甚至下降平均響應(yīng)時間急劇上升失敗率開始出現(xiàn)這個點就是系統(tǒng)當(dāng)前的一個性能拐點。5.3 結(jié)果數(shù)據(jù)的自動化提取與分析手動查看每個輸出文件效率低下。我們可以用grep,awk等命令快速提取關(guān)鍵指標(biāo)生成CSV格式便于導(dǎo)入Excel或數(shù)據(jù)分析工具進行繪圖和對比。#!/bin/bash # extract_metrics.sh # 遍歷所有結(jié)果文件 for file in result_*.txt; do # 從文件名提取并發(fā)數(shù)例如 result_50.txt - 50 concurrency$(echo $file | grep -o -E ‘[0-9]’) # 使用awk提取關(guān)鍵指標(biāo) qps$(grep “Requests per second:” “$file” | awk ‘{print $4}’) # 提取用戶視角的平均時間第一行Time per request time_per_req$(grep “Time per request:” “$file” | head -1 | awk ‘{print $4}’) failed$(grep “Failed requests:” “$file” | awk ‘{print $3}’) # 提取90%響應(yīng)時間 p90$(grep “90%” “$file” | awk ‘{print $2}’) # 輸出CSV格式的一行 echo “${concurrency}, ${qps}, ${time_per_req}, ${failed}, ${p90}” done運行./extract_metrics.sh metrics.csv你會得到一個包含并發(fā)數(shù)、QPS、平均響應(yīng)時間、失敗數(shù)、P90響應(yīng)時間的表格可以輕松地繪制出“并發(fā)數(shù)-QPS”和“并發(fā)數(shù)-響應(yīng)時間”曲線圖直觀地展示系統(tǒng)性能變化。6. 常見問題、性能瓶頸分析與排查指南在實際使用ab進行壓測時你會遇到各種問題。下面是一些典型場景和排查思路。6.1 ab工具自身限制與誤區(qū)“Socket: Too many open files (24)” 錯誤 這是Linux系統(tǒng)限制。ab每個并發(fā)連接都需要一個文件描述符。當(dāng)并發(fā)數(shù) (-c) 設(shè)置過高時可能超過用戶或系統(tǒng)的最大文件打開數(shù)限制。解決方案臨時提高限制ulimit -n 65535(僅對當(dāng)前Shell會話有效)。永久修改編輯/etc/security/limits.conf添加* soft nofile 65535和* hard nofile 65535重啟后生效。檢查系統(tǒng)全局限制cat /proc/sys/fs/file-max如果太小可以通過sysctl -w fs.file-max100000修改。測試機成為瓶頸 這是新手最容易忽略的問題。ab是單進程的雖然能發(fā)起很多并發(fā)連接但其請求發(fā)送和接收統(tǒng)計都在一個進程內(nèi)。如果測試的QPS非常高例如數(shù)萬測試機本身的CPU可能被ab進程占滿或者網(wǎng)絡(luò)帶寬被打滿導(dǎo)致無法對服務(wù)器施加足夠壓力測出的結(jié)果偏低。排查方法在運行ab時另開一個終端在測試機上運行top觀察ab進程的CPU使用率。如果接近100%說明測試機是瓶頸。運行sar -n DEV 1查看網(wǎng)絡(luò)接口的吞吐量rxkB/s, txkB/s如果接近網(wǎng)卡帶寬上限也是瓶頸。解決方案使用性能更強的測試機或者采用分布式壓測用多臺機器同時跑ab?！癮pr_socket_recv: Connection reset by peer (104)” 錯誤 服務(wù)器主動重置了連接。這通常是因為服務(wù)器在高壓下崩潰、重啟或者達到了其連接數(shù)限制如Nginx的worker_connections主動斷開了連接。排查方向立即檢查服務(wù)器日志如nginx error.log,dmesg查看是否有“out of memory”、“worker_connections are not enough”、“socket overflow”等錯誤。6.2 服務(wù)器端性能瓶頸定位當(dāng)ab報告顯示QPS低、響應(yīng)時間長或失敗率高時問題通常在服務(wù)器端。你需要登錄服務(wù)器進行系統(tǒng)級和應(yīng)用級排查。系統(tǒng)級瓶頸排查使用命令行工具CPU瓶頸運行top或htop。如果%us(用戶態(tài)CPU) 或%sy(系統(tǒng)態(tài)CPU) 長期高于80%說明CPU是瓶頸。進一步用pidstat -u 1或top -Hp [pid]查看是哪個進程或線程消耗CPU最多。內(nèi)存瓶頸運行free -m或top。觀察available內(nèi)存是否充足。如果swap使用量 (Si,So) 在vmstat 1輸出中持續(xù)不為0說明物理內(nèi)存不足發(fā)生了內(nèi)存交換性能會急劇下降。磁盤I/O瓶頸運行iostat -x 1。關(guān)注%util(利用率)如果持續(xù)接近100%說明磁盤I/O飽和。同時觀察await(平均等待時間)如果很高說明磁盤響應(yīng)慢。網(wǎng)絡(luò)瓶頸運行sar -n DEV 1。觀察網(wǎng)絡(luò)接口的吞吐量是否接近帶寬上限。也可以使用iftop查看實時流量。應(yīng)用級瓶頸排查Web服務(wù)器配置檢查Nginx/Apache的配置。關(guān)鍵參數(shù)包括worker_processes/StartServers工作進程數(shù)建議設(shè)置為CPU核心數(shù)。worker_connections/MaxClients單個進程的最大連接數(shù)。確保其值大于你的測試并發(fā)數(shù)。keepalive_timeout長連接超時時間。適當(dāng)調(diào)大有助于提升性能。應(yīng)用服務(wù)器/框架查看應(yīng)用日志是否有大量錯誤、超時或慢查詢?nèi)罩?。對于Java應(yīng)用關(guān)注GC日志頻繁的Full GC會導(dǎo)致停頓。對于Python/Node.js等檢查是否有阻塞操作或內(nèi)存泄漏。數(shù)據(jù)庫/緩存這是最常見的瓶頸源。在壓測時監(jiān)控數(shù)據(jù)庫的CPU、連接數(shù)、慢查詢。檢查緩存命中率是否過低。6.3 測試結(jié)果不穩(wěn)定的常見原因服務(wù)器有緩存第一次訪問和后續(xù)訪問性能差異巨大。解決方案在正式測試前先使用ab進行幾輪預(yù)熱Warm-up讓服務(wù)器的緩存如數(shù)據(jù)庫查詢緩存、應(yīng)用層緩存熱起來然后再開始正式測試并記錄結(jié)果。外部依賴服務(wù)不穩(wěn)定如果你的應(yīng)用依賴其他API或服務(wù)它們的性能波動會直接影響你的測試結(jié)果。盡量在隔離的環(huán)境如壓測專用數(shù)據(jù)庫、Mock外部服務(wù)下進行測試。測試環(huán)境干擾測試環(huán)境與別人共享資源被搶占。盡量在獨立的、干凈的機器上進行測試。JIT編譯影響針對Java/PHP等應(yīng)用服務(wù)器在啟動初期JIT編譯器尚未優(yōu)化熱點代碼性能會較差。預(yù)熱一段時間后性能才會達到穩(wěn)定。這也是需要進行預(yù)熱測試的原因之一。避坑技巧實錄一次真實的性能調(diào)優(yōu)案例我曾壓測一個返回JSON數(shù)據(jù)的API初始QPS只有120。ab報告顯示Time per request很高。服務(wù)器CPU使用率卻不高。首先我懷疑是網(wǎng)絡(luò)但sar顯示網(wǎng)絡(luò)流量很低。查看Nginx錯誤日志發(fā)現(xiàn)大量*1024 worker_connections are not enough while connecting to upstream警告。原來是Nginx到后端應(yīng)用服務(wù)器的連接池滿了。調(diào)整Nginx配置增加了upstream塊中的keepalive連接數(shù)并增大了worker_connections。再次壓測QPS提升到300但CPU依然空閑。使用curl -w “\ntime_total: %{time_total}\n”手動測試發(fā)現(xiàn)DNS解析時間占了大部分。原來API URL用的是域名每次請求Nginx都要解析。在Nginx的upstream中直接使用IP地址或者在Nginx的http塊中配置resolver并啟用緩存。最終壓測QPS穩(wěn)定在了850左右。關(guān)鍵教訓(xùn)性能瓶頸可能出現(xiàn)在任何環(huán)節(jié)客戶端、網(wǎng)絡(luò)、Web服務(wù)器、應(yīng)用服務(wù)器、數(shù)據(jù)庫。需要結(jié)合ab的報告和系統(tǒng)的全方位監(jiān)控像偵探一樣一層層排查。ab告訴你“病了”性能差而其他工具幫你找到“病因”瓶頸點。