怎樣正確做 Web 應用的壓力測試？

01-04

大家一般如何做壓力測試？比如怎樣判斷一個應用的承受能力，在到達何種程度時需要增加伺服器？請大家講一下經驗~

感謝 @ZeldaZzz 的回答，針對Web應用測試和伺服器配置分享兩個實用幫助。

傳送門：如何部署伺服器和如何進行Web測試

希望能幫助大家~

單機的壓力測試(包括functional test)，我平時都用python的FunkLoad

遇到大的壓力測試，使用erlang開發的tsung會比較好，可以分散式測試

他們都是open source的

壓力測試的目標，是搞死伺服器，從而找到瓶頸點，如果搞不死，意義就不大

性能測試是答主的弱項

回憶一下當初的做法趁機整理一下思路

BTW

這個問題好老

也許題主現在已經成為性能測試專家了

希望能看到題主的更新共同討論

答主認為

所有的測試都是為了驗證軟體是否符合客戶需求

測試不是追求零缺陷、軟體質量無限好

而是追求軟體的質量剛剛好或者比客戶需求好一點點

性能測試也不例外

所以性能測試的設計應該考慮

1）客戶需求，並

2）為軟體改進和升級提供參考數據

先說性能測試用例的設計

應該了解產品

a 最頻繁使用功能

b 最耗資源功能

c 設計峰值並發用戶數

等等與客戶行為真正相關的東西

自動測試角本應該最起碼要模擬a和b兩部分功能

而且是盡量模擬真實的用戶使用習慣

所以性能測試人員一定一定一定要懂功能測試

否則我很懷疑測試用例的有效性

再說性能測試環境

最理想的當然是有一套硬、軟體都與生產環境完全一致的測試環境

但這個在絕大多數公司都是不現實的

畢竟造價太高了

比較接近現實的是有一套獨立的測試環境

最起碼是在性能測試期能專門用於性能測試

把整個環境全部清零

按部就班安裝所需的軟體

開始性能測試收集第一組數據

環境再清零

重跑相同測試收集第二組數據

這個過程起碼做三遍或者更多

三組數據對比沒有重大差異

說明測試用例和測試環境穩定、測試結果可信

否則說明有疏漏測試結果不可信需要查找原因重新測試

在正式測試前應該起碼確保環境穩定、測試角本正確

大部分的性能測試工具可以模擬並發用戶數

基礎的性能測試應該先按設計的峰值用戶數跑測試用例

但因為上面說了

大部分性能測試環境配置會比生產環境低一些

那麼按峰值用戶數跑性能一定會比設計指標低

甚至低到慘不忍睹

我沒有找到一個合理的辦法

把測試環境上收集的指標折算成生產環境上的指標

我覺得這太不現實了

我採取的辦法是

設峰值用戶數為A

那麼在性能測試上用A/3並發用戶數做為起始點

（原諒我的測試環境配置太低了）

收集三組數據取平均值

然後每次遞增一定數量的並發用戶數收集數據

直到性能差到系統接近崩潰

用所得數據繪製趨勢圖

應該可以找到在測試環境上並發用戶數與性能的曲線

這個可以做為生產環境的參考曲線

而且這樣方式

還有助於發現系統的瓶頸

是在CPU、內存、IO還是網路

也能幫助發現代碼問題

比如答主在測試中曾經發現用某個模塊跑性能測試時

CPU的表現不對

後來發現是那個模塊的代碼多線程處理有問題

bug修復後性能明顯改善

暫時想起來這麼多

testcomplete，loadrunner，這些只是工具。

1、了解被測試應用的協議，

2、了解被測系統的組成，

3、編寫壓力測試腳本，

4、生成壓力

5、監控系統

6、收集並分析數據

7、得出結論

第一個回答就給你吧。

性能測試，難點在於你確認要測什麼？是壓力測試還是負載測試。這點很重要，如果這2個概念你還不清楚，請搜索。

其次在於如何確定測試策略和測試指標。也就是在性能測試中常說的測試場景。這個選擇的面和方法很複雜。可以另開題在說了。這裡就說步驟好了。

以上確認完畢後，再次確認測試環境，內網，無網路問題，帶寬足夠，線上，線下伺服器配置相同，架構同樣。緩存設置，等等一系列。

OK了，以上都確認完畢了，可以看看選擇什麼工具了。簡單的AB WB JM 複雜的LR 對吧。選擇方法另說。

以上都OK了，才可以按照測試策略來進行測試。

這只是到了性能測試的實施階段。後續還有調優，複測，。。。。。。。循環100次。

所以說，你這個問題問的巨大無比，一些同學的回復，上來就大談工具。都是不正確的。工具只是這裡邊最簡單的一環。性能測試，不是簡單的一點二點就說清楚的。上邊的每一條展開了說都是一部長篇，供您參考

不同系統對最大負載的要求不一樣。就通常的web網站來說基本指標是：在合理的響應時間內，系統能提供最大的每秒請求數（QPS/RPS/TPS）。其中幾個關鍵點：一、合理響應時間，3-5s是一個合格的網站渲染首屏最多花費的時間，如果單純看最大qps而不管響應時間的話，這個測試是無意義的；二、每個頁面包含的功能不一樣多，所以指標也定不相同，那麼訪問最頻繁的頁面的性能指標應該是我們最關注的；三、web網站大多讀寫急不平衡，但在有持續寫入的情況下測試出來的指標與單純讀指標的對比，對判斷鎖的性能很有幫助；最重要的一點是，剛創業的站點應多注意快速開發業務，心裡有性能這根弦，不犯愚蠢錯誤就足夠了。等站點真正做出來再回頭調優，應該是個甜蜜的過程。

jmeter+badboy再外加一個自己寫的monitor監控，用起來還比較順手，主要就是用來做web壓力測試

經典的自然是loadrunner，可以進行並發壓力測試，

很實用，可以模擬多IP，多用戶同時運行，

可以設置運行間隔，建議你還是去網上搜索一個相關的教程來看一下吧

一般都是使用工具，可以模擬多用戶同時/非同步地進行

比較好的工具，要錢的有loadrunner

不要錢的有JMeter

這2種工具都能自動生成圖形報告。這樣你就能判斷出伺服器的瓶頸在哪裡。是需要增加內存還是提高處理器性能，或者增加硬碟。

試一下 OneAPM的CPT雲壓測。

支持5種協議：HTTP、HTTPS、WebSocket、Socket、MQTT

支持測試腳本自動錄製、手工編輯、日誌導入等多種方式

支持數據替換支持 CSV 格式文件讀取，數據讀取替換方式支持順序、隨機、分段多種模式

支持5種常用數據格式自動化替換：日期時間、隨機數字、唯一數字、迭代數字、用戶唯一數業務數據支持上下文自動關聯
, 數據定位準確操作方便快捷

支持多種參數自動化加密：AES、DES、RSA、MD5、SHA1，自有加密演算法包調用

錄製回放數據一體化展示 , 回放日誌直觀明確, 錯誤數據清晰易讀

場景編輯

壓測節點遍布全球，亞馬遜、阿里雲、微軟雲、青雲、百度雲、騰訊雲、金山雲、過，國美雲、美團雲、電信雲、華為雲、Ucloud、自建IDC資源

5分鐘開啟壓測資源，用戶無需準備任何壓測環境

測試區域在地圖中直觀選取 , 滿足不同用戶的各類需求

多種真實性能測試場景任意設置，平台模式、梯度模式、壓力模式的場景滿足各類業務系統需求日誌級別分為標準、參數、錯誤、調試，可以準確的排查業務問題用戶的載入斜率與生產中的數據模型保持無限接近，多腳本、多區域自定義比例儘可能的模擬用戶期望的真實場景無限接近真實的線上壓測體驗讓複雜性能問題無可遁形

查看報告

豐富的性能指標

性能指標：並發用戶數、錯誤率、吞吐量、每秒點擊數、每秒響應數、事務平均響應時間、每秒事務數、每秒事務總數等

基礎硬體指標：CPU、內存、磁碟、網路流量、網路連接等

資源細分指標：HTML、圖片、JS、介面等響應時間精確詳細

多區域維度數據聯動分析：全球多區域的性能訪問數據實時在線分析，幫助用戶快速定位網路問題，優化後讓用戶體驗更加均衡流暢

CPT+AI解決方案

在壓測過程中，可對事務耗時深入到各應用組件, 自定義事務深入到執行線, 資料庫監控下鑽至 SQL
執行計劃, 誤定位到代碼行及錯誤堆棧信息

分享一個案例：

有個做旅遊和攝影服務平台的客戶要舉辦一次活動，為本次活動製作了專門的活動頁面，在活動頁面用戶可以報名。那麼在短時間內系統到底能撐得住多大的用戶並發？

這是活動運營和技術部門必須提前考慮的問題，因為在去年舉辦類似活動時就出現了用戶大量湧入導致服務不可用的狀況，所以首先要幫助用戶整理容量測試和規劃的工作思路。

具體該如何實施壓測呢，這裡劃分了幾個環節：

1場景確定與壓測腳本準備

用戶在註冊時需要提交用戶的姓名、手機號和手機驗證碼，之後提交申請即可，所以實際上用戶申請註冊只調用了一個API介面來完成，這是一個比較簡單的場景。

1、因為涉及到手機驗證場景，在不提供對應API的情況下，建議用戶使用萬能的驗證碼或者暫時取消驗證碼；

2、是否允許多個手機號同時註冊，如果允許我們可用使用固定參數傳遞，如果不允許，我們可準備對應手機號的測試數據來應對；

3、短時間內發起大量並發，用戶本身是否有安全擋板，如果有，需要把施壓節點的IP加入白名單；

2施壓模式

既然是容量探測，所以整體的施壓過程是一個梯度漸進的過程，一般不會上來就是一條直線。這是一直和用戶強調的問題，壓測的目的絕對不是把系統壓垮，壓測的目的是通過不斷增加的並發來客觀評估系統在不同的壓力條件下的性能狀況；基於此我們定製了施壓的梯度壓力模式，如圖所示：

3壓測點分布

傳統壓力測試工具主要在內網產生壓力，壓力的規模受限於物理機器及License數量，造成準備周期長及成本高等問題。而雲壓測提供可靠的分散式壓測伺服器（壓測點），充分利用雲端的計算資源，從而突破了這個限制。

目前雲智慧的壓測點來自雲服務的雲主機（AWS、Ucloud和阿里雲等）以及雲智慧部署在全國各大IDC核心機房的伺服器，目前主要提供的區域如下圖所示：

4壓測時間設定

根據系統訪問情況，一般會建議用戶在凌晨進行壓測，此時能夠保證對用戶的影響最小，也能保證正常用戶訪問對壓測結果的干擾最小。但這個壓測時間設定不是絕對的，需要與具體用戶的業務場景結合判斷。

5壓測數據分析

在基本的參數確定之後，就可用根據預定的時間來執行壓測任務了，雲壓測能夠進行秒級的數據採集和實時統計分析，能夠隨時調整壓力。隨著壓力的逐步上升，能夠動態呈現系統的性能數據。在逐步加壓的過程中，如果性能急劇下降或大量出錯，就沒有必要繼續執行壓測任務，此時可以終止任務，也可以下調壓力，確保對整個壓測過程的把控。

針對這個用戶，按照上述步驟實施壓力測試之後，通過相關測試結果的數據分析和評估，得到了壓測結論如下：

被壓測的註冊介面在360並發用戶以下時表現相對良好，在並發用戶達到360至500時性能欠佳，說的更直接一點就是：該系統能夠支撐360的並發，具體論證如下：

1、並發達到360之後失敗明顯增多並且持續到任務結束；

2、並發達到420之後，響應時間超出3000ms標準值且持續到最後；

3、每秒鐘事務數（TPS）穩定在130左右，表現比較良好；

本次壓測的概要數據如下圖所示：

壓力測試綜合報表如下圖所示，當並發用戶數達到360時，系統開始出現了大面積失敗（280時出現了1次錯誤），並且失敗問題持續到壓測結束都沒有改善，不過整個測試過程中並沒有出現斷言不匹配的情況，即正確性保持良好。

事務響應時間趨勢：隨著應用訪問用戶量增加，在並發用戶達到420的時候，系統事務處理的時間也顯著上升（大於參考標準3000ms），且響應時間在以後一直沒有下降。

事務處理性能趨勢：當壓力穩步上升後，應用事務處理能力保持平穩，基本維持在每秒鐘處理130個左右事務，該數值基本能保障並發用戶註冊的需求。

涉及到到壓測工具為自壓測寶

某政務網站性能優化

看看別人怎麼做的，能找找感覺

要做壓力測試，首先要選擇好工具，俗話說：「工欲善其事，必先利其器」

請看這篇文章：介紹幾款Web伺服器性能壓力測試工具

看了下答案，除了談工具的還是談工具的。

不過題主的問題也是太大了，網站應用性能是個系統工程，是涉及到網站架構各個層面，從前端渲染速度，到頁面大小，session存儲效率，ajax性能，緩存命中率，資料庫設計及訪問速度。

而要做整體性能測試則需要根據預計的用戶訪問目標或者已有的用戶訪問統計數據搭建整體應用訪問場景進行，不單單要模擬用戶請求還要根據用戶場景模擬資料庫數據量。

以上這些隨便挑一個都是相當複雜的話題，這些僅僅是壓測判斷系統瓶頸，還不包括系統負載和穩定性。

然後，第二個問題也只有在系統可以平行擴展的情況加伺服器才能有效，而有些情況下則需要優先考慮架構調整及程序的優化。

1. "簡單"的應用,可以用apache自帶的工具ab測試. 也可以試試http_load;

2. 一般給一個大概的性能評測報告,評估需要多少伺服器. 多點餘量無妨;

3. 注意記錄好各種數據. 在什麼時候需要增加伺服器更多的是考驗運維的能力.

如何描述一個web應用的性能模型，簡單來說，應該是PV(PageView)+RT(Response Time)。

一般我們經常會看到一些網站發布數據說，我們的網站一天的PV是多少多少，這其實就就是一個很直觀的性能數據。

PV其實說的就是業務量：你的系統在可接受的RT內，所承受的PV就是系統的處理能力；當然我們更關注的是單位時間內的PV，比如每秒的PV，這代表你系統所能承受的並發能力；

我一貫的觀點是，壓力測試更多的是發現潛在的問題，其實沒有辦法告訴你他能支撐多大的業務量；這其中主要的問題在於業務的快速變化和用戶行為的不可預知。

增加伺服器一般就是處理能力不夠了，比如cpu繁忙，io繁忙；當然很多時候，業務系統的擴展性決定了你的應用是不是能通過增加伺服器的方式提高處理能力；更多的是要找到問題，對症下藥。

web應用壓力測試分為消息層，業務層，直接訪問效率。

1）消息層java相關的可以用Jmeter。應用服務是apache用ab

2）業務層可以用lr鏈接sql來插數據

3）直接訪問效率 WAS

多去了解下性能測試然後再來做這個

最好的壓力測試，從線上流量複製過來，再乘以2。具體的方式，有實時導流的，也把線上的accesslog拿下來當原材料的。至於工具、圖表那些很多都能用，沒什麼影響。

apache 的 ab