如何對日誌伺服器壓力測試

1. 網站伺服器如何做訪問壓力測試

網站伺服器的壓力測試我覺得主要有一些幾點。
1.協議這邊基本上以http或者https為主了，如果使用其他協議需要分析其打解包的方法。
2.要產生一定的壓力，壓力源這邊一定要有保證。一般都是用機器人來模擬壓力，關於機器人的邏輯可以根據具體業務來開發。
3.需要觀察在一定壓力下，伺服器的各項性能指標（cpu，內存，IO，網路流量）進行觀察，比如內存是否有泄漏，cpu利用率過高的情況。
4.壓力測試應該是一個持續性的過程，在這個過程中需要統計伺服器的性能數據，包括tps，以及機器的負載情況等。據此可以分析伺服器的瓶頸在何處，後續可以針對優化。
5.目前大部分的伺服器都部署在Linux系統上，測試同學還需要掌握相關的Linux命令以便可以更好的測試。
如果你覺得前面的太麻煩，可以來WeTest伺服器壓力測試高並發，實時性能報表，專家級性能優化建議，目前我們正在做網站壓測這一塊，你要做的僅僅是填下被測的URL即可，壓力源、數據統計這些瑣碎的工作交給我們就行了。

2. 想要進行伺服器的壓力測試有什麼軟體推薦一下

首先要是針對伺服器壓力測試（指的是伺服器硬體的情況）的話，針對windows系統話可以通過批處理腳本進行壓力測試，如果是liunx系統話可以通過ab測試工具進行測試。
如果針對web性能測試的話，可以通過loadrunner進行測試，網上的相關教程很多，書也有，學起來比較簡單的

3. 求客戶端（app）對伺服器的壓力測試怎麼做，急急急！

性能測試就是壓力測試，手機方面的其實和PC方面的差距不大，重點就是大量手機調用介面對伺服器的壓力，所以測試的重點還是在伺服器上，你可以用Jmeter模擬介面報文，來並發壓伺服器，看伺服器的響應和處理能力。單個手機畢竟是一個人在用，所以一般不用關心手機端的問題。手機端主要的就是功能沒什麼問題，只要app玩著玩著不要崩潰掉就行了.

4. 怎樣測試伺服器壓力

下載並安裝WAST；

1．設置並行連接數；

2．設置持續時間；

3．其餘設置；

註：所有以上的選項可以根據自己的需要進行設置。

設置完成後就可以進行壓力測試。測試的步驟如下：

第一步，點擊工具欄上的「New Script」按鈕，在打開的面板中點擊「Nanual」按鈕創建一個新的測試項目。在打開的窗口中對它進行設置，在主選項中的Server中填寫要測試的伺服器的IP地址。這里我們填寫192.168.1.20。在下方選擇測試的Web連接方式，這里的方式Verb選擇get。Path選擇要測試的Web頁面路徑，這里填寫/Index.asp即動網的首頁文件，WAST可以設置更多的Path。

第二步，在「Settings」功能設置中將Stress Level （Threads）線程數設置為1000。然後點工具中的灰色三角按鈕即可進行測試。測試過程中我們可以從伺服器的任務管理器中看到CPU使用率已經達到100%，損耗率達到最大。在CMD窗口中使用命令netstat -an，可以看到客戶端的IP地址在伺服器上的80埠進行了非常多的連接，而且Web網站已經打不開了，提示過多用戶連接。

5. 集中式日誌分析平台 - ELK Stack - Filebeat 壓測

任何一款採集 agent 進行公司內全面推廣前都需要進行性能測試以及資源限制功能測試，以保證：

對於 Filebeat 這款號稱 golang 編寫，性能強於 logstahs-forwarder 的採集 agent，我們也需要這樣進行嚴謹對待。

硬體選擇虛擬機，6cores + 16GB Mem + 175GB SSD + 1000Mbps 帶寬；

Filebeat 配置，輸出到 console：

Filebeat 配置，輸出到 Kafka：

我們開啟 Filebeat 的 6060 埠，並使用 python 腳本進行指標採集。
expvar_rates.py ，每秒統計出 Filebeat 指標，主要看：

Step1. 啟動 Filebeat (172.16.134.8)

Step2. 啟動統計腳本

Step3. 啟動 tsar

Step4. 寫入壓測數據(6個進程寫入，6千萬條日誌)

在 6 進程數據寫入日誌文件時，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致占據了 0.8 cores。
在 6 進程數據寫入日誌文件後，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致占據了 1.6 cores。
小結：

測試步驟和上述一致，區別在於配置文件需要輸出到 Kafka。
在 6 進程數據寫入日誌文件時，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致占據了 0.7~0.8 cores。
在 6 進程數據寫入日誌文件後，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致占據了 2.0 cores。
小結：

測試步驟和上述一致，區別在於配置文件需要輸出到 Kafka。
和上述步驟不同的是，啟動 Filebeat 時需要 systemd 限制 CPU、句柄數，根據之前的理論，句柄數限制在 100 已經非常夠用，CPU 限制在 1 core。
修改 /usr/lib/systemd/system/filebeat.service ：

執行 reload：

對 CPU 進行限制：

確認是否限製成功：

有如下輸出表示OK：

在 6 進程數據寫入日誌文件時，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致占據了 0.7 ~ 0.8 cores。
在 6 進程數據寫入日誌文件後，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致占據了 1.0 cores，限制生效。
小結：

在 6 進程數據寫入日誌文件時，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致占據了 0.75 ~ 0.9 cores。
在 6 進程數據寫入日誌文件後，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致占據了 1.0 cores，限制生效。
小結：

在 6 進程數據寫入日誌文件時，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致占據了 0.7 ~ 0.75 cores。
在 6 進程數據寫入日誌文件後，我們在開啟 python 統計腳本的窗口得到如下穩定的統計數據：

我們在 tsar 看到的統計數據為：

我們在 top 中可以看到 Filebeat 大致占據了 0.9 cores，未達到限制。
小結：

A. FB 全力採集 247B 數據(真實環境類似日誌長度)，速率為 ~ 40K/s，CPU 開銷為 2 cores；

B. FB 在 CPU 限制 1 cores 情況下，採集 247B 數據速率為 ~ 20K/s，可以認為單核採集速率為 ~ 20K/s/core；

C. 日誌單行數據越大，吞吐越小，5KB 每行已經非常誇張，即使如此，沒有壓縮的情況下帶寬消耗 35MBps，gzip 壓縮率一般為 0.3~0.4，佔用帶寬為 10.5~14MBps，對於千兆網卡來說壓力較小；

6. 如何對伺服器進行壓力測試

http_load是基於Linux平台的一種性能測工具。它是以並行復用的方式運行，僅適用於Web頁面的性能測試，不適用於訪問資料庫，而且測試結果分析是有限的，平台依賴Linux 。http_load可以簡單地通過txt文本文件中記錄的參數來對HTTP伺服器進行壓力測試，那是如何對伺服器進行壓力測試的呢?下面我們就來介紹 Linux中如何安裝使用http_load對伺服器進行壓力測試的教程。 具體方法步驟如下： 1、下載 官方網站：acme/software/http_load/http_load-12mar2006.tar.gz tar xzf http_load-12mar2006.tar.gz 2、安裝 代碼如下： cd http_load-12mar2006 make 執行完make，會在當前目錄生成一個http_load二進制文件。 3、使用方法 代碼如下： root@www：~/http_load-12mar2006# 。/http_load --help usage： 。/http_load [-checksum] [-throttle] [-proxy host:port] [-verbose] [-timeout secs] [-sip sip_file] -parallel N -rate N [-jitter] -fetches N -seconds N url_file One start specifier， either -parallel or -rate， is required. One end specifier， either -fetches or -seconds， is required. 主要參數說明： -parallel 簡寫-p ：含義是並發的用戶進程數。 -rate 簡寫-r ：含義是每秒的訪問頻率 -fetches 簡寫-f ：含義是總計的訪問次數 -seconds簡寫-s ：含義是總計的訪問時間 選擇參數時，-parallel和-rate選其中一個，-fetches和-seconds選其中一個。 4、示例： 代碼如下： http_load -parallel 50 -s 10 urls.txt 這段命令行是同時使用50個進程，隨機訪問urls.txt中的網址列表，總共訪問10秒。 代碼如下： http_load -rate 50 -f 5000 urls.txt 每秒請求50次，總共請求5000次停止。 測試網站每秒所能承受的平均訪問量： 代碼如下： http_load -parallel 5-fetches 1000urls.txt 這段命令行是同時使用5個進程，隨機訪問urls.txt中的網址列表，總共訪問1000次。運行之後的結果： 1000 fetches， 5 max parallel， 6e+06 bytes， in 58.1026 seconds 6000 mean bytes/connection 17.2109 fetches/sec， 103266 bytes/sec msecs/connect： 0.403263 mean， 68.603 max， 0.194 min msecs/first-response： 284.133 mean， 5410.13 max， 55.735 min HTTP response codes： code 200 — 1000 從上面的運行結果來看，目標網站僅僅能夠承受每秒17次訪問，不夠強壯。

7. 如何做壓力測試

一個壓力測試的流程：

1、明確測試目標

2、制定測試計劃

3、實施測試，收集參數

4、分析測試結果

5、給出優化方案

一 、明確測試目標：如果是客戶的需求，那需要向客戶確認，有清楚的性能指標參數，測試時就是保證系統達到該指標並能良好運轉，即壓力測試。如果是自己的系統需要有一個評估，那就需要完整的得到該系統的幾個臨界點，拿到完整的性能曲線，從而來分析部署情況，即為性能測試。不管是哪個，知道了需求，才能制定計劃。

性能測試的目標是發現重大的系統瓶頸。你可以想像一個系統由一系列的瓶頸組成；發現並改善一個瓶頸往往會在其他地方產生一個新的瓶頸。例如，我曾為一運行微軟Windows CE的器件部門工作。我們發現的第一大性能問題體現在某一具體硬體環境下的內存管理中。我們把問題分離出來，改善了內存分配的效率。爾後再次運行我們的測試，又找到了一個新的瓶頸，這次體現在網路吞吐量上（throughput）。解決了這個問題後，我們接著又為下一個瓶頸改善而工作，然後再下一個，直到整個系統都達到了性能目標。要記住的是：關鍵在於要盡早訂立性能目標，否則你可能不知道什麼時候該停止性能測試。

二、制定測試計劃：確定使用什麼工具，著重哪些參數，設置線程數，方法執行次數，執行時間，是否多個介面同時進行測試等等。

三、實施測試，收集參數：選一個施壓工具，來向部署好的服務發起高並發請求，同時關注和收集性能參數。這個是我們花費時間最多的地方。通常該階段需要反復執行，來得到想要的數據。通常來說，我們可以使用JMeter LR AB 自己寫多線程等各種方式，之後介紹一下JMeter。

四、分析測試結果：即根據上一節的參數介紹來進行參數分析。

五、給出優化方案：如果是代碼邏輯耗費cpu，就優化演算法；如果是redis等資料庫耗時，就增加節點，減少讀取，讀寫分離，使用內存等；如果是外在條件限制，則與外部們溝通問題，共同優化等等。

8. 游戲上線前伺服器壓力測試應該怎麼做

對於游戲後台性能，評測標准不只單單是TPS（每秒處理多少個XX請求），因為當你的游戲伺服器上線後，不存在一群玩家只發XX請求的壓力場景。所以，游戲後台受到的現網請求壓力永遠是多場景混合的，在這樣的壓力下，後台能支撐多少人同時在線，才是一個游戲壓測者需要得到的有價值的測試結論。
要得到可支撐的"最大同時在線人數"，主要做好2件事：
1、設計你的類現網壓力模型
在現網真實壓力里，不瞎卜論壓力大小如何變化，現網環境如何變化，一個游戲類型和玩法設計定型後，永遠有2個壓力宏觀數據保持不變：a. 各介面的壓力比例不變， b.玩家平均每分鍾操作頻率不變。因此，壓力測試目標就轉變成了如何模擬符合ab數據的壓力。
對於a，首先從同類型游戲或者本游戲內測階段，日誌插樁，收集各個介面的調用比例；然後，將介面比例轉化為場景比例，如同時會有個2%完結登陸、15%玩家戰斗余神粗、20%玩家拉取好友列表、10%玩家賭博（一個手游場景例子）。
對於b，同樣在內測階段收集玩家平均操作頻率。
此時有了a和b，就可以構造出一分鍾豎鎮內玩家同時在線的真實壓力模型了。
2、用壓測工具構造出符合壓力模型的壓力
這個可以自己寫，也可以使用現成的壓測工具。現在市面上的壓測工具很多，但很多都是專注於TPS這個參數，不符合游戲行業壓測的關注點，同時在線人數。

9. 如何利用ApacheBench進行伺服器壓力測試

方法/步驟
1
比較常用的命令，如：
ab -n 請求數 -c 並發數 URL
2
跑了一個簡單的Demo：
usertekiMacBook-Pro:~ zhaoxianlie$ ab -n 200 -c 10 http://127.0.0.1:8793/
This is ApacheBench, Version 2.3 <$Revision: 1554214 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.jinbanz.com/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Finished 200 requests

Server Software:
Server Hostname: 127.0.0.1
Server Port: 8793

Document Path: /
Document Length: 28012 bytes

Concurrency Level: 10
Time taken for tests: 6.847 seconds
Complete requests: 200
Failed requests: 0
Total transferred: 5665503 bytes
HTML transferred: 5601103 bytes
Requests per second: 29.21 [#/sec] (mean)
Time per request: 342.343 [ms] (mean)
Time per request: 34.234 [ms] (mean, across all concurrent requests)
Transfer rate: 808.07 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 148 338 93.2 335 633
Waiting: 148 337 93.3 335 633
Total: 148 338 93.2 336 634

Percentage of the requests served within a certain time (ms)
50% 336
66% 371
75% 397
80% 413
90% 461
95% 500
98% 568
99% 610
100% 634 (longest request)
3
這其中Requests per second、Time per request算是褲舉大家都比較看重的兩個評估參數了吧。
不過對於這種壓力測試來說，也不能一上來就 -n 1000 -c 10，還是得慢慢來，一開始可以來一個 -n 50 -c 10這樣子，逐漸網上增加，取Request per second的最大值作為Http server的性能指標，應該會靠譜一些。
假設我的這個測試伺服器RPS峰值是30，那一分鍾能扛過來的請求差不多 1800 個，這是單核CPU的情況下。
假設是我廠伺服器的配置，24核，開啟Node的cluster模式，RPS應該是此橘倍數增加的，明胡扒碧天去公司找台服務壓測一把。如果真是這樣，那麼每秒鍾能扛過來的請求差不多 720 個，換算到一個小時，是259.2w個訪問請求。
假設伺服器配置是Nginx+Node，Nginx做負載均衡，proxy_pass對應的upstream配置到4台Node伺服器，且每台Node伺服器均衡負載，那麼，一個小時能扛得動的流量基本是 1kw多一些，滿負荷跑一天，2.4億的流量了。