基于Locust 的Web 性能測試工具設計

摘要：隨著Web應用的普及和用戶對響應速度要求的不斷提升，確保Web應用在高并發(fā)環(huán)境下的性能成為開發(fā)過程中的關鍵環(huán)節(jié)。為了更高效地對Web應用進行性能測試，文章設計了一種基于Locust框架的Web性能測試工具，旨在通過分布式架構實現(xiàn)多臺測試機同時施壓，達到真實有效的高并發(fā)目的，通過軟件方式解決傳統(tǒng)測試中資源消耗占用率高的問題。文章結合Web開發(fā)技術將性能測試結果以可視化圖表進行實時展示，支持關鍵指標圖表聯(lián)動，方便用戶進行數(shù)據(jù)分析。該工具支持HTTP/HTTPS協(xié)議的Web應用測試，支持梯形場景設計，同時結合操作系統(tǒng)和中間件的性能監(jiān)控指標，利用Prometheus和Grafana構建實時監(jiān)控體系，實現(xiàn)對Web應用服務響應的全方位監(jiān)控與分析。經過測試，該工具具有良好的可行性和實用性。

關鍵詞：Web應用；Locust；性能測試；可視化圖表；全方位監(jiān)控

中圖分類號：TP311 文獻標識碼：A

文章編號：1009-3044（2024）27-0008-04

0 引言

軟件作為信息化時代的重要載體，尤其是商業(yè)軟件日用戶量巨大，上線之前必須經過性能驗證，否則容易引發(fā)服務宕機、軟件崩潰等問題。用戶操作邏輯是用戶與Web應用交互的核心，其合理性和效率直接影響用戶體驗和應用性能[1]，因此將性能效率風險貫穿于軟件方案論證、軟件設計研發(fā)及軟件產品交付整個過程中具有重要意義。

目前市場上已有很多Web性能測試工具，但使用較多的高并發(fā)工具主要有收費的LoadRunner和開源的JMeter。社區(qū)版本LoadRunner只能滿足模擬極少數(shù)用戶并發(fā)，且不能用于商業(yè)用途；商業(yè)版本Load?Runner能夠模擬大量用戶并發(fā)，但工具價格昂貴、操作復雜且可移植性不強[2]。JMeter是一款開源性能測試工具，JMeter通過線程組來驅動多個線程運行測試腳本對被測服務器發(fā)起負載[3]，可通過修改配置文件實現(xiàn)施壓機級聯(lián)，但對用戶來說操作比較煩瑣，測試效率不高。除上述兩種常見工具外，不少企業(yè)嘗試自研測試工具，如文獻[4]提出了一種基于FabanPlus工具的Web軟件性能自動化測試方法，但缺少監(jiān)控手段和可視化展示。本文設計了一種基于Locust框架的Web性能測試工具，該工具通過分布式架構實現(xiàn)高效的并發(fā)請求生成與調度，并將測試結果以可視化圖表進行展示。同時結合操作系統(tǒng)和中間件的性能監(jiān)控指標，利用Prometheus和Grafana構建實時監(jiān)控體系，可以實現(xiàn)對Web應用服務響應的全方位監(jiān)控與分析。

1 Locust 簡介

Locust框架是一款使用Python編寫的開源性能測試工具，主要應用在分布式測試、API壓力測試、性能瓶頸識別、負載能力評估以及Web應用性能測試。它以其易用性、可擴展性、實時監(jiān)控和高度可定制等優(yōu)勢，目前已經被眾多開發(fā)測試人員用于大型系統(tǒng)的復雜壓力測試。隨著云計算和微服務架構的普及，Lo?cust在分布式系統(tǒng)和API性能測試方面的優(yōu)勢將更加明顯，其在性能測試領域的地位也將進一步提升。Locust相比其他基于進程和線程的測試工具，摒棄了系統(tǒng)級資源調度，采用協(xié)程（gevent） 來實現(xiàn)高并發(fā)。這使得Locust在單機上能夠產生更高的并發(fā)請求數(shù)，同時保持較低的資源消耗。其主要特點包括：使用普通Python腳本定義測試場景，具有基于Web的用戶界面以實時監(jiān)控腳本運行狀態(tài)。

2 工具總體架構設計

本設計共有6個功能模塊，其中并發(fā)引擎是核心，負責整個軟件的運行調度、數(shù)據(jù)計算。由并發(fā)引擎發(fā)起模擬請求，直接向服務器施加壓力，接收服務器返回的響應數(shù)據(jù)；仿真錄制用于獲取用戶對被測軟件任意操作的快照信息，將請求以腳本的方式傳遞給并發(fā)引擎，由并發(fā)引擎發(fā)起模擬行為；場景設計為高并發(fā)測試用戶提供場景設計接口，由用戶確定并發(fā)用戶數(shù)、啟動模式、持續(xù)時長等關鍵場景信息；負載設定用于設置資源信息以及每臺壓測機發(fā)起的事務比例。并發(fā)引擎獲取負載設定傳入的參數(shù)后，根據(jù)該參數(shù)進行任務調度；數(shù)據(jù)處理主要能力在于將并發(fā)引擎反饋的數(shù)據(jù)做進一步處理，生成TPS等指標信息，對測試過程數(shù)據(jù)進行存儲，為性能分析提供基礎數(shù)據(jù)；可視化顯示部分是基于Web技術研發(fā)的數(shù)據(jù)展示頁面，將指標數(shù)據(jù)和過程數(shù)據(jù)以直觀的方式向用戶進行呈現(xiàn)；監(jiān)控系統(tǒng)主要是通過軟件探針抓取資源使用數(shù)據(jù)并以圖表的方式展示，該部分支持自定義模板設置。圖1 為工具總體架構圖。

3 工具功能設計

3.1 仿真錄制

仿真錄制是實現(xiàn)用戶行為模擬的重要環(huán)節(jié)，其核心是對基于HTTP/HTTPS協(xié)議的Web應用進行網(wǎng)絡數(shù)據(jù)監(jiān)聽。為了實現(xiàn)網(wǎng)絡數(shù)據(jù)截取，首先要配置proxy網(wǎng)絡代理，并為該代理指定代理端口，使用Fiddler對指定端口上的數(shù)據(jù)進行捕獲。本設計基于Chrome瀏覽器實現(xiàn)，啟動仿真錄制服務后，fzService服務會接收Fid?dler獲取的數(shù)據(jù)包，并按照Har標準協(xié)議編排。通過仿真錄制服務可以收集用戶在Web應用上的任何行為，包括該行為背后客戶端和服務端之間的請求頭、響應頭、響應體、Cookie、時間戳等所有網(wǎng)絡信息。

本設計基于HTTP/HTTPS 協(xié)議進行Web應用錄制。其中HTTP協(xié)議采用明文傳輸，可以直接查看報文詳情。HTTPS協(xié)議采用雙向加密后，F(xiàn)iddler以中間人身份獲取報文后，由于沒有密鑰，無法直觀查看報文信息。對于HTTPS協(xié)議，由于加密原因并不是完全無法獲知明文，可以在加密通信建立之前，獲取服務器中含有證書的報文，并替換該證書后發(fā)送給客戶端。收到客戶端包含密鑰的對稱加密報文后，以服務端公鑰完成加密發(fā)送給服務器，如此相當于獲取解密后的服務數(shù)據(jù)，接下來便可以對相應的報文信息進行保存和修改。

錄制結束生成Har文件后，便可以進行網(wǎng)絡重放，驗證錄制到的網(wǎng)絡信息是否與用戶的操作行為一致。

3.2 負載設定

由于性能驗證在高并發(fā)壓力下進行，施壓機對于CPU、內存以及帶寬的需求比較大，因此需要將請求分配到多臺施壓機上，以此來完成壓力測試。將需要的服務包上傳到指定的兩臺施壓機，完成服務安裝，并設定好主從關系。本文將負載的worker（輔助進程）指向負載master（主進程）的IP即可，主從進程通過消息參數(shù)完成主從節(jié)點間的跨節(jié)點通信。當主從機上的任務啟動時，服務會對仿真錄制的Har文件進行解析，進而按照腳本中定義的串行事件進行執(zhí)行。任務執(zhí)行時，系統(tǒng)支持權重設置，來調節(jié)每個機器上運行的事務數(shù)。

3.3 并發(fā)場景設計

性能測試聚焦于通過模擬特定場景下的壓力活動，旨在達成預設測試目標。性能測試中的場景設計是實施性能測試的基礎，場景設計一般在錄制腳本完成后進行[5]。并發(fā)場景設計以梯形模式、線性模式、震蕩模式最為常見，涉及的主要參數(shù)有并發(fā)用戶數(shù)、login session間隔以及運行總時長。

本設計高并發(fā)場景為梯形模式，用戶可根據(jù)實際使用需要設置用戶并發(fā)量、用戶增長間隔以及運行時長。用戶增長間隔默認為秒，當用戶輸入并發(fā)用戶數(shù)和用戶增長所需時間后，后臺服務自動計算每秒上線的用戶數(shù)。用戶一旦上線完成，按照腳本中的請求順序執(zhí)行并發(fā)任務，模擬用戶運行到設定的執(zhí)行時間后，自動退出。本設計并發(fā)引擎基于Python語言的gevent、requests等庫文件，參數(shù)化可通過在相應的請求事務節(jié)點，用戶根據(jù)場景設計需要以Python代碼方式完成。

在場景設計中，需要對系統(tǒng)的平均并發(fā)用戶數(shù)進行估值，估值公式如式（1） ：

C = nL/T （1）

式中，C 代表平均并發(fā)用戶數(shù)，n 代表login session 的數(shù)量，L 代表login session完成該事務的時長，T 代表運行的總時長。

獲取平均并發(fā)量后可以按照該值進行峰值并發(fā)量估算，估值公式如式（2） ：

式中，峰值并發(fā)量用D 來表示。該估值的前提是login session按照泊松分布產生。

對于響應處理能力，通常使用的是TPCC估值，該估值計算的是系統(tǒng)每分鐘處理的請求個數(shù)。實際上，該指標也是衡量服務器處理能力的一個重要參照。

該估值體系充分考慮了軟件實際運行中的并發(fā)用戶數(shù)、用戶訪問模式、軟件處理的事務中各個業(yè)務占比、經驗系數(shù)以及服務器必須保留的冗余比例。

3.4 并發(fā)引擎

本設計并發(fā)引擎依賴于Locust框架的gevent庫，該庫提供了豐富的二次開發(fā)接口，主要能力在于底層的greenlent微線程機制，按照傳入的參數(shù)發(fā)起所需協(xié)程，協(xié)程最大的特點是支持單機高并發(fā)量。LoadRun?ner和JMeter使用的是線程機制，線程是操作系統(tǒng)級別的并發(fā)執(zhí)行單元，每個線程擁有自己的執(zhí)行堆棧和程序計數(shù)器，由操作系統(tǒng)內核管理。線程是重量級的執(zhí)行單元，其創(chuàng)建和切換成本相對較高，因為涉及系統(tǒng)級的上下文切換。協(xié)程的切換速度比線程快10倍左右，協(xié)程是程序級別的執(zhí)行單元，運行在線程之上，由程序控制而不是由操作系統(tǒng)內核管理。協(xié)程是輕量級的，其創(chuàng)建和切換成本非常低，協(xié)程的切換是在用戶級別進行的，不需要系統(tǒng)級的上下文切換。在協(xié)程內由代碼控制運行邏輯，因此可控制協(xié)程在頻繁I/O 處理時暫停而不至于將線程阻塞。

本設計集成了Python的requests庫以支持HTTP 與HTTPS協(xié)議的訪問控制，確保網(wǎng)絡交互的廣泛兼容性和安全性。同時使用pyzmq庫實現(xiàn)服務的分布式部署，允許服務跨越多個機器或進程并發(fā)運行。面對高并發(fā)請求場景，系統(tǒng)后臺依據(jù)用戶定義的主從關系策略，通過pyzmq動態(tài)啟動引擎服務，并借助gevent庫的協(xié)程機制，在并發(fā)腳本中高效地執(zhí)行HTTP/HTTPS 請求，從而在不增加額外資源開銷的前提下，實現(xiàn)高并發(fā)事務處理。

3.5 數(shù)據(jù)處理

高并發(fā)執(zhí)行過程中會產生大量數(shù)據(jù)。例如，在萬級并發(fā)量的情況下，系統(tǒng)運行中每秒產生的過程數(shù)據(jù)量是用戶量的幾何倍數(shù)。在龐大的數(shù)據(jù)量下，測試工具采樣頻率和采樣精度直接關系到性能效率結果的正確性。本文對TPS、RPS、平均響應時間等以秒為單位進行數(shù)據(jù)更新，即對于指標更新，在基于之前采樣數(shù)據(jù)進行運算的基礎上，一秒后重新運算并更新數(shù)據(jù)，防止頻繁更新引起緩存以及CPU資源的浪費。對于復雜結構數(shù)據(jù)，計算精度按照規(guī)則做截斷處理，指標項的數(shù)據(jù)精度只保留到小數(shù)點后5位。

高并發(fā)過程中產生的數(shù)據(jù)主要有三種：項目信息、過程數(shù)據(jù)和報告信息。數(shù)據(jù)處理模塊對產生的數(shù)據(jù)進行分析統(tǒng)計，生成需要的指標信息。針對高并發(fā)效率驗證的特點，本文對不同的數(shù)據(jù)采取不同的處理手段。項目信息在項目創(chuàng)建階段將項目ID、項目名稱等在數(shù)據(jù)庫中進行存儲，腳本信息則以索引的方式與項目進行關聯(lián)。高并發(fā)過程中產生的動態(tài)數(shù)據(jù)如TPS、平均響應時間等使用Redis進行存儲，項目結束后Redis自動清空。高并發(fā)過程中用于單個用戶進行追蹤的數(shù)據(jù)以及系統(tǒng)運行時產生的日志信息，該種數(shù)據(jù)的特點是數(shù)據(jù)量大、內存占用高，但對用戶進行腳本調試、錯誤追蹤、用戶行為分析又必不可少。本設計中將該類數(shù)據(jù)以文件的方式直接在相應的施壓機進行存儲，避免頻繁進行SQL連接，減少數(shù)據(jù)庫連接和關閉的次數(shù)。通過文件方式查找過程數(shù)據(jù)在性能測試中相對更加便捷高效。高并發(fā)性能效率驗證結束后，最終的TPS、RPS、平均響應時間、最大響應時間、最小響應時間、T50、T90等報告信息，在運行時長結束后，立即執(zhí)行數(shù)據(jù)庫操作，并將該數(shù)據(jù)與項目ID 進行關聯(lián)。

3.6 數(shù)據(jù)監(jiān)控系統(tǒng)

數(shù)據(jù)監(jiān)控系統(tǒng)以Prometheus開源軟件為中心進行結果展示。將操作系統(tǒng)、中間件Kafka、Redis等中間件以及數(shù)據(jù)庫MySQL相應的pointer探針程序啟動后，在Prometheus 的YAML 文件中進行配置，指向pointer 探針的IP 和端口以及程序名稱。Prometheus 啟動后便可以獲取pointer探針采集到的監(jiān)控數(shù)據(jù)，Prometheus將檢測數(shù)據(jù)發(fā)送到Grafana軟件頁面進行數(shù)據(jù)展示。Grafana具備強大的界面顯示能力，除了基礎的數(shù)據(jù)展示外，還可供使用者進行二次開發(fā)，使用者按照自己的顯示風格進行頁面設計。

3.7 可視化顯示

Locust框架處理后的結果數(shù)據(jù)以Ajax收發(fā)請求的方式反饋給前端頁面，前后端之間通過HTTP、Web?Socket協(xié)議實現(xiàn)數(shù)據(jù)通信。本文前端采用Vue框架，獲取Ajax請求數(shù)據(jù)后，實現(xiàn)測試結果的圖表和文本信息展示。

4 測試結果分析

為驗證本文設計的Web性能測試工具的功能，以Web學生管理系統(tǒng)為被測對象。Web學生管理系統(tǒng)主要功能涵蓋添加學生信息、修改學生信息、查詢學生信息和刪除學生信息等。服務端部署在Windows10操作系統(tǒng)，處理器為11th Gen Intel（R） Core（TM） i5-1135G7 @ 2.40GHz 2.42 GHz，內存16 GB 的機器上。針對該系統(tǒng)共設計三種測試場景：

1） 單用戶按照業(yè)務流程操作軟件進行登錄、添加人員、修改人員、查詢人員和刪除人員作業(yè)，打開記錄瀏覽器調試頁面，記錄相應執(zhí)行函數(shù)的網(wǎng)絡響應時間，測試結果如表1所示。

2） 腳本調試完成后，將并發(fā)用戶數(shù)設置為1，按照串行方式執(zhí)行登錄、添加人員、修改人員、查詢人員和刪除人員事務，并記錄其響應時間，測試結果如表1 所示。

3） 對該學生管理系統(tǒng)進行Web性能測試，模擬100個用戶進行登錄，登錄后每個用戶分別進行多次添加人員、修改人員、查詢人員和刪除人員操作，測試時長為3分鐘，具體事務數(shù)和測試結果顯示效果如圖2所示。性能測試結果的可視化展示效果如圖3所示。

根據(jù)測試結果可知，單用戶通過瀏覽器進行手工作業(yè)完成相應業(yè)務的響應時間和通過工具測試完成相應事務的響應時間誤差在2%以內，證明工具模擬測試結果與軟件實際響應完全一致。

在并發(fā)狀態(tài)下，登錄事務僅并發(fā)一次，事務數(shù)為100，表示全部用戶登錄成功。登錄事務平均響應時間為99ms、TPS為10.5。由于登錄事務包含軟件初始化請求，服務端執(zhí)行函數(shù)較多，該響應數(shù)據(jù)符合學生管理系統(tǒng)的軟件架構設計要求和服務器的硬件配置的響應能力。在100用戶并發(fā)的情況下，每秒新增人員30.12個，接收速率為209.55kb/s。該事務的接收速率明顯高于其他修改人員、查詢人員和刪除人員事務，是因為該事務包含頁面靜態(tài)信息，服務端吞吐壓力因此比其他事務較大。修改人員平均響應時間為35ms，TPS為31.15。該事務是基于新增人員事務基礎上進行的并發(fā)壓測，無資源請求接口，因此與增加人員相比，在TPS保持基本不變的情況下，平均響應時間優(yōu)于增加人員事務。查詢人員事務數(shù)、平均響應時間、TPS均低于其他事務，因為在進行并發(fā)查詢前，數(shù)據(jù)庫已經預置50 萬條人員信息，且查詢SQL 為慢SQL，因此該事務響應指標較低，符合軟件實際運行狀態(tài)。刪除人員事務平均響應時間為1072ms，該事務響應時長最大是因為該事務包含人員二次確認操作。用戶發(fā)起刪除事務后，服務端并未執(zhí)行刪除程序，而是向用戶發(fā)起確認指令，經過用戶二次確認后，才執(zhí)行刪除事務，因此平均響應時間較大。

并發(fā)狀態(tài)下，各項事務響應時間明顯高于單用戶狀態(tài)，是因為并發(fā)狀態(tài)下，服務器處理的請求明顯增多，系統(tǒng)處理能力降低。實際測試結果與預期結果一致，證明該并發(fā)測試結果有效。

5 結束語

本文設計的Web性能測試工具實現(xiàn)了基于HTTP/HTTPS 協(xié)議的Web應用請求錄制，實現(xiàn)腳本編寫自動化，節(jié)約腳本開發(fā)的時間成本并一定程度規(guī)避人工編寫腳本引入的錯誤語句。并基于Locust 的pyzmq庫函數(shù)實現(xiàn)施壓機分布式部署和運行，以協(xié)程方式發(fā)起并發(fā)請求，提高單機測試并發(fā)量，減少對高性能施壓機的依賴。按照高并發(fā)性能驗證需求，將測試結果數(shù)據(jù)與過程數(shù)據(jù)分開存儲，方便用戶對異常響應的定位分析。構建以Prometheus為核心，pointer探針為數(shù)據(jù)源，Grafana為展示面板的數(shù)據(jù)監(jiān)控系統(tǒng)，以可視化圖表的方式為用戶提供實時高并發(fā)過程信息。經過測試，該工具可以有效收集Web應用的性能數(shù)據(jù)并進行分析，一定程度上提高了性能測試的執(zhí)行效率。后續(xù)本設計將繼續(xù)豐富場景設計模式，增加線性場景、震蕩場景研究開發(fā)，并進一步探索請求參數(shù)自動化，實現(xiàn)腳本錄制與腳本參數(shù)化深度關聯(lián)。

參考文獻：

[1] 邵曉峰.Web應用性能優(yōu)化中的前端加載策略研究[J].信息記錄材料，2024，25（3）：35-37.

[2] 趙斯琦，劉如才.Web性能測試工具分析及Gatling改進[J].網(wǎng)絡安全和信息化，2023（3）：162-164.

[3] 唐承玲，王虎，李光平，等.基于JMeter的Web性能測試研究[J].電腦與電信，2021（6）：65-68，86.

[4] 周健，曹曉龍，吳琦.Web軟件性能參數(shù)自動化測試方法設計[J].電子設計工程，2023，31（16）：112-115，120.

[5] 李金萌.基于LoadRunner的資產管理系統(tǒng)應用[J].無線互聯(lián)科技，2022，19（10）：43-46.

【通聯(lián)編輯：謝媛媛】

基金項目：2022 年江蘇省教育科學規(guī)劃課題（項目編號：B/2022/02/90） ；中國職業(yè)技術教育學會第五屆理事會2022 年科研規(guī)劃課題（項目編號：ZJ2022A16） ；江蘇省現(xiàn)代教育技術研究課題（項目編號：2021-R-87049）