壓測、防止壓測方案
1. 壓測
(1) 壓測工具:ab
(2) 壓測請求方式：get
(3) 壓測網域名稱：url
(4) 壓測方案：10萬請求，
500併發
(5) 壓測指令碼
ab -n 100000 -c 500 url
(6) 展示壓測結果
從上面分析，10萬請求錯誤有
96881
次請求錯誤，基本上也就是很大的問題了
(7) nginx訪問日誌監控http返回狀態
進一步分析：很明顯，日誌記錄瞬間很多請求，有好多http 都是503伺服器錯誤，這些是壓測併發的請求，有一些是
200，這些是正常請求的，訪問是
ok的。
(8) top監控程序狀態
① 壓測前:
② 壓測中：
(9) 解決方案
通過第八點分析：很明顯，php-fpm程序數，瞬間增加到6個子程序，nginx增加到3個子程序，並且
nginx
占用的cpu
為43.7
，40.0
，20.5
；並且ab程序也佔了80.4，也就是10萬請求，
500併發的情況下，在這個機器上面，
cpu超負荷了，很顯然
cpu是跟不上的，需要提公升，當然可以根據具體情況應對具體的措施。
2. 通過第一大點，可以看出壓測對伺服器是很可怕的，我們在壓測的同時，還需要做到，預防第三方的惡意壓測，這裡有
(1)
net.ipv4.tcp_syncookies = 0 （vim /etc/sysctl.conf 這裡面可以看到）
這個是作業系統核心的乙個引數，在高併發的情況下，核心會認為系統受到了syn flood攻擊，會傳送
cookies
（possible syn flooding on port 80. sending cookies
），這樣會減慢影響請求的速度，所以在應用服務**上設定下這個引數為
0禁用系統保護就可以進行大併發測試了，如果設定為
1，那麼就會出現
apr_socket_recv: connection reset by peer (104)
，不讓併發通過
net.ipv4.tcp_syncookies = 0 的時候，全部請求通過
net.ipv4.tcp_syncookies = 1 的時候，請求擋掉了
由此可見，這個可以預防惡意壓測
(2)
limit_conn_zone等相關配置
limit_conn為限制併發連線數；
http中配置
limit_conn_zone $binary_remote_addr zone=perip:10m;
server中配置
limit_conn perip 10;
limit_rate_after 1m;
limit_rate 100k;
配置之前如下：
配置後如下：
很明顯cpu利用率沒有那麼高了，以上是兩種預壓測的方案，當然還有其他的方案，不一一舉例
Jmeter 壓測和AB壓測的比較
使用場景 jmeter告訴你每個請求實際上耗費多長時間。ab只是簡單的用數學方式統計平均值。所以從準確性來說，jmeter比ab更準確，更多如資料處理。但是ab的速度更快，更輕巧。如果效能測試的目的在於更真實的表現被測應用，那麼jmeter更佳。但如僅僅是用最少的機器資源產生最多的訪問請求，那ab適...
壓測 mysql關閉連線 MySQL 壓測
mysqlslap iterations 100 create schema test query query.sql number of queries 20000 delimiter concurrency 100 3.2.2 網路引數問題 問題描述 使用mysqlslap 壓測某個語句，當併發...
Python併發 壓測http 壓測rpc
思路 啟動max workers個workers 執行緒 每個執行緒處理乙份輸入資料。如果自己統計，那還需要對下邊的指令碼進行擴充套件。如果搭配grafana等監控工具使用，那壓測指令碼只負責瘋狂發請求就好了。import concurrent.futures def parallel proces...