web壓力測試檢測
轉載：https://zhuanlan.zhihu.com/p/97303549
在項目上線之前，都需要做壓力測試，目的是看下我們的網站能抗住多少的壓力，能承擔多少併發，如果不做壓力測試，一旦出現大訪問量時，我們的網站會掛掉。
一、Webbench測試併發
Webbench是Linux下的一個網站壓力測試工具，能測試處在相同硬件上，不同服務的性能以及不同硬件上同一個服務的運行狀況。webbench的標準測試可以向我們展示服務器的兩項內容：每分鐘相應請求數和每秒鐘傳輸數據量。webbench最多可以模擬3萬個併發連接去測試網站的負載能力。
測試的環境是 Linux Ubuntu
安裝
┌──(root💀kali)-[~] └─# apt-get install exuberant-ctags 正在讀取軟件包列表... 完成 正在分析軟件包的依賴關係樹... 完成 正在讀取狀態信息... 完成 下列【新】軟件包將被安裝： exuberant-ctags 升級了 0 個軟件包，新安裝了 1 個軟件包，要卸載 0 個軟件包，有 582 個軟件包未被升級。 需要下載 156 kB 的歸檔。 解壓縮後會消耗 358 kB 的額外空間。 獲取:1 https://mirrors.aliyun.com/kali kali-rolling/main i386 exuberant-ctags i386 1:5.9~svn20110310-15 [156 kB] 已下載 156 kB，耗時 0秒 (326 kB/s) 正在選中未選擇的軟件包 exuberant-ctags。 (正在讀取數據庫 ... 系統當前共安裝有 271253 個文件和目錄。) 準備解壓 .../exuberant-ctags_1%3a5.9~svn20110310-15_i386.deb ... 正在解壓 exuberant-ctags (1:5.9~svn20110310-15) ... 正在設置 exuberant-ctags (1:5.9~svn20110310-15) ... update-alternatives: 使用 /usr/bin/ctags-exuberant 來在自動模式中提供 /usr/bin/ctags (ctags) update-alternatives: 使用 /usr/bin/ctags-exuberant 來在自動模式中提供 /usr/bin/etags (etags) 正在處理用於 kali-menu (2021.2.3) 的觸發器 ... 正在處理用於 man-db (2.9.4-2) 的觸發器 ... Scanning processes... Scanning linux images... Running kernel seems to be up-to-date. No services need to be restarted. No containers need to be restarted. No user sessions are running outdated binaries. ┌──(root💀kali)-[~] └─# wget http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz --2021-09-23 12:35:53-- http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz 正在解析主機 home.tiscali.cz (home.tiscali.cz)... 82.208.6.172 正在連接 home.tiscali.cz (home.tiscali.cz)|82.208.6.172|:80... 已連接。 已發出 HTTP 請求，正在等待迴應... 200 OK 長度：7675 (7.5K) [application/x-tar] 正在保存至: “webbench-1.5.tar.gz” webbench-1.5.tar.gz 100%[================>] 7.50K --.-KB/s 用時 0s 2021-09-23 12:35:54 (422 MB/s) - 已保存 “webbench-1.5.tar.gz” [7675/7675]) ┌──(root💀kali)-[~] └─# ls 公共 模板 視頻 圖片 文檔 下載 音樂 桌面 webbench-1.5.tar.gz ┌──(root💀kali)-[~] └─# tar zxvf webbench-1.5.tar.gz webbench-1.5/ webbench-1.5/webbench.1 webbench-1.5/socket.c webbench-1.5/webbench.c webbench-1.5/Makefile webbench-1.5/debian/ webbench-1.5/debian/rules webbench-1.5/debian/dirs webbench-1.5/debian/copyright webbench-1.5/debian/control webbench-1.5/debian/changelog webbench-1.5/COPYRIGHT webbench-1.5/ChangeLog ┌──(root💀kali)-[~] └─# cd webbench-1.5/ ┌──(root💀kali)-[~/webbench-1.5] └─# make cc -Wall -ggdb -W -O -c -o webbench.o webbench.c webbench.c: In function ‘alarm_handler’: webbench.c:77:31: warning: unused parameter ‘signal’ [-Wunused-parameter] 77 | static void alarm_handler(int signal) | ~~~~^~~~~~ cc -Wall -ggdb -W -O -o webbench webbench.o ctags *.c ┌──(root💀kali)-[~/webbench-1.5] └─# make install install -s webbench /usr/local/bin install -m 644 webbench.1 /usr/local/man/man1 install -d /usr/local/share/doc/webbench install -m 644 debian/copyright /usr/local/share/doc/webbench install -m 644 debian/changelog /usr/local/share/doc/webbench ┌──(root💀kali)-[~/webbench-1.5] └─# webbench webbench [option]... URL -f|--force Don't wait for reply from server. -r|--reload Send reload request - Pragma: no-cache. -t|--time <sec> Run benchmark for <sec> seconds. Default 30. -p|--proxy <server:port> Use proxy server for request. -c|--clients <n> Run <n> HTTP clients at once. Default one. -9|--http09 Use HTTP/0.9 style requests. -1|--http10 Use HTTP/1.0 protocol. -2|--http11 Use HTTP/1.1 protocol. --get Use GET request method. --head Use HEAD request method. --options Use OPTIONS request method. --trace Use TRACE request method. -?|-h|--help This information. -V|--version Display program version. ┌──(root💀kali)-[~/webbench-1.5] └─# webbench -c 100 -t 10 http://baidu.com/ 2 ⨯ Webbench - Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://baidu.com/ 100 clients, running 10 sec. Speed=31044 pages/min, 14706 bytes/sec. Requests: 386 susceed, 4788 failed.
1.1 安裝ctags
apt-get install exuberant-ctags
ctags 爲webbench的依賴
1.2 下載安裝
官網：http://home.tiscali.cz/~cz210...
root@corwien:~# wget http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz root@corwien:~# tar zxvf webbench-1.5.tar.gz root@corwien:~# cd webbench-1.5/ root@corwien:~/webbench-1.5# make root@corwien:~/webbench-1.5# make install root@corwien:~/webbench-1.5# webbench webbench [option]... URL -f|--force Don't wait for reply from server. -r|--reload Send reload request - Pragma: no-cache. -t|--time <sec> Run benchmark for <sec> seconds. Default 30. -p|--proxy <server:port> Use proxy server for request. -c|--clients <n> Run <n> HTTP clients at once. Default one. -9|--http09 Use HTTP/0.9 style requests. -1|--http10 Use HTTP/1.0 protocol. -2|--http11 Use HTTP/1.1 protocol. --get Use GET request method. --head Use HEAD request method. --options Use OPTIONS request method. --trace Use TRACE request method. -?|-h|--help This information. -V|--version Display program version.
2、測試
用法：
// webbench -c 併發數 -t 運行測試時間 URL webbench -c 100 -t 10 http://baidu.com/
這裏使用百度做個試驗 ^_^：
測試結果：
結果分析：
每秒鐘響應請求數:1443/60= X pages/sec，每秒鐘傳輸數據量2691621 bytes/sec。
當併發500時，成功請求1402個，已經顯示有41個連接failed了，說明超負荷了。
3、小結：
1、壓力及性能測試工作應該放到產品上線之前，而不是上線以後；
2、測試時併發應當由小逐漸加大，比如併發100時觀察一下網站負載是多少、打開頁面是否流暢，併發200時又是多少、網站打開緩慢時併發是多少、網站打不開時併發又是多少；
3、更詳細的進行某個頁面測試，如電商網站可以着重測試購物車、推廣頁面等，因爲這些頁面佔整個網站訪問量比重較大。
備註：webbench 做壓力及性能測試時，該軟件自身也會消耗CPU和內存資源，爲了測試準確，建議將 webbench 安裝在其他的服務器上，已達到測試數據更加精確。
二、實戰
上邊學習了怎樣使用webbench來做壓力測試，現在就用這個工具來測試下自己的博客，我的博客服務器使用的是阿里雲ECS，當併發由100 到 500時，看下服務器的CPU使用率和內存使用情況，當併發數過多時，CPU會不會被佔用完，網站此時還能否正常訪問，我們的目的就是測出網站能抗住多少的併發量。
1、使用 top 命令查看服務器資源使用情況
在實測之前，首先學下top命令的參數含義：
top命令是Linux下常用的性能分析工具，能夠實時顯示系統中各個進程的資源佔用狀況，類似於Windows的任務管理器。
top顯示系統當前的進程和其他狀況,是一個動態顯示過程,即可以通過用戶按鍵來不斷刷新當前狀態.如果在前臺執行該命令,它將獨佔前臺,直到用戶終止該程序爲止. 比較準確的說,top命令提供了實時的對系統處理器的狀態監視.它將顯示系統中CPU最“敏感”的任務列表.該命令可以按CPU使用.內存使用和執行時間對任務進行排序；而且該命令的很多特性都可以通過交互式命令或者在個人定製文件中進行設定.
root@hey:~# top -d 2 top - 01:22:59 up 690 days, 9:42, 1 user, load average: 0.09, 0.05, 0.05 Tasks: 117 total, 2 running, 115 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.5 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.5 st KiB Mem: 1016272 total, 886640 used, 129632 free, 163252 buffers KiB Swap: 1048572 total, 37120 used, 1011452 free. 449744 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15875 root 20 0 139156 15048 9420 S 0.5 1.5 15:17.66 AliYunDun 1 root 20 0 33372 1388 320 S 0.0 0.1 0:21.49 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
統計信息區前五行是系統整體的統計信息。第一行是任務隊列信息，同 uptime 命令的執行結果。其內容如下：
01:22:59 當前時間 up 690 days, 9:42, 系統運行時間，格式爲 天，時:分 1 user, 當前登錄用戶數 load average: 0.09, 0.05, 0.05 系統負載，即任務隊列的平均長度。三個數值分別爲 1分鐘、5分鐘、15分鐘前到現在的平均值。
第二、三行爲進程和CPU的信息。當有多個CPU時，這些內容可能會超過兩行。內容如下：
total 進程總數 running 正在運行的進程數 sleeping 睡眠的進程數 stopped 停止的進程數 zombie 殭屍進程數 Cpu(s): 0.3% us 用戶空間佔用CPU百分比 1.0% sy 內核空間佔用CPU百分比 0.0% ni 用戶進程空間內改變過優先級的進程佔用CPU百分比 98.7% id 空閒CPU百分比 0.0% wa 等待輸入輸出的CPU時間百分比 0.0%hi：硬件CPU中斷佔用百分比 0.0%si：軟中斷佔用百分比 0.0%st：虛擬機佔用百分比
最後兩行爲內存信息。內容如下：
Mem: 191272k total 物理內存總量 173656k used 使用的物理內存總量 17616k free 空閒內存總量 22052k buffers 用作內核緩存的內存量 Swap: 192772k total 交換區總量 0k used 使用的交換區總量 192772k free 空閒交換區總量 123988k cached 緩衝的交換區總量,內存中的內容被換出到交換區，而後又被換入到內存，但使用過的交換區尚未被覆蓋，該數值即爲這些內容已存在於內存中的交換區的大小,相應的內存再次被換出時可不必再對交換區寫入。
進程信息區統計信息區域的下方顯示了各個進程的詳細信息。首先來認識一下各列的含義。
序號 列名 含義 a PID 進程id b PPID 父進程id c RUSER Real user name d UID 進程所有者的用戶id e USER 進程所有者的用戶名 f GROUP 進程所有者的組名 g TTY 啓動進程的終端名。不是從終端啓動的進程則顯示爲 ? h PR 優先級 i NI nice值。負值表示高優先級，正值表示低優先級 j P 最後使用的CPU，僅在多CPU環境下有意義 k %CPU 上次更新到現在的CPU時間佔用百分比 l TIME 進程使用的CPU時間總計，單位秒 m TIME+ 進程使用的CPU時間總計，單位1/100秒 n %MEM 進程使用的物理內存百分比 o VIRT 進程使用的虛擬內存總量，單位kb。VIRT=SWAP+RES p SWAP 進程使用的虛擬內存中，被換出的大小，單位kb。 q RES 進程使用的、未被換出的物理內存大小，單位kb。RES=CODE+DATA r CODE 可執行代碼佔用的物理內存大小，單位kb s DATA 可執行代碼以外的部分(數據段+棧)佔用的物理內存大小，單位kb t SHR 共享內存大小，單位kb u nFLT 頁面錯誤次數 v nDRT 最後一次寫入到現在，被修改過的頁面數。 w S 進程狀態(D=不可中斷的睡眠狀態,R=運行,S=睡眠,T=跟蹤/停止,Z=殭屍進程) x COMMAND 命令名/命令行 y WCHAN 若該進程在睡眠，則顯示睡眠中的系統函數名 z Flags 任務標誌，參考 sched.h
默認情況下僅顯示比較重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。可以通過下面的快捷鍵來更改顯示內容。
更改顯示內容通過 f 鍵可以選擇顯示的內容。按 f 鍵之後會顯示列的列表，按 a-z 即可顯示或隱藏對應的列，最後按回車鍵確定。
按 o 鍵可以改變列的顯示順序。按小寫的 a-z 可以將相應的列向右移動，而大寫的 A-Z 可以將相應的列向左移動。最後按回車鍵確定。
按大寫的 F 或 O 鍵，然後按 a-z 可以將進程按照相應的列進行排序。而大寫的 R 鍵可以將當前的排序倒轉。
命令使用
top使用格式
top [-] [d] [p] [q] [c] [C] [S] [s] [n]
參數說明
d 指定每兩次屏幕信息刷新之間的時間間隔。當然用戶可以使用s交互命令來改變之。
p 通過指定監控進程ID來僅僅監控某個進程的狀態。
q 該選項將使top沒有任何延遲的進行刷新。如果調用程序有超級用戶權限，那麼top將以儘可能高的優先級運行。
S 指定累計模式
s 使top命令在安全模式中運行。這將去除交互命令所帶來的潛在危險。
i 使top不顯示任何閒置或者僵死進程。
c 顯示整個命令行而不只是顯示命令名
2、壓測並同時查看服務器top資源使用情況
500併發量壓測
root@corwien:~# webbench -c 500 -t 60 http://myblog.com/index.php
壓測結果：
500個併發，在60秒內，請求成功2172個，失敗數225個
我們再看下在壓測時，服務器的資源使用情況：
通過上邊的三張圖，我們可以看到，當500併發壓測時，空閒CPU百分比越來越少，由99.0 id 減少到 41.3 id 再到 0.0 id，壓測結束時，又恢復到正常的水平，99.0 id。說明我的網站500併發就扛不住了，CPU資源消耗完了，這時如果訪問我的網站，會出現 502 的情況。所以，根據壓測結果，可以更好的對網站的硬件配置進行提升和對站點的靜態優化。