一、前言

http_load是一款測試web服務器性能的開源工具，從下面的網址可以下載到最新版本的http_load：

http://www.acme.com/software/http_load/?（頁面實在太簡陋……）

十分令人欣慰的是，這個軟件一直在保持著更新（不像webbench，已經是十年的老古董了。webbench的源碼分析請參考：http://www.cnblogs.com/xuning/p/3888699.html ），并且更新頻率還蠻高的樣子。我在下載了2014年8月2號的版本后，緊接著8月14號再查看，就又有了一個新的版本。這篇文章分析的http load版本是“http_load 02aug2014”，好在每個版本之間差別非常小，本文還是具有較好的通用性的。

?

二、使用方法

下載并解壓縮之后，進入工具的根目錄直接make，就可以得到可執行的工具。其使用方法如下圖所示：

圖中所示的url.txt內容是若干url鏈接，每行一個，比如：http://127.0.0.1:80/index.html。

詳細說明一下使用格式：

./http_load [-checksum] [-throttle] [-proxy host:port] [-verbose] [timeout secs] [-sip sip_file]

???????? -parallel N | -rate N [-jitter]

???????? -fetches N | -seconds N

???????? url_file

選項與參數：

-fetches：總計要訪問url的次數，無論成功失敗都記為一次，到達數量后程序退出。

-rate：每秒訪問的次數（即訪問頻率），控制性能測試的速度。

-seconds：工具運行的時間，到達seconds設置的時間后程序退出。

-parallel：最大并發訪問的數目，控制性能測試的速度。

-verbose：使用該選項后，每60秒會在屏幕上打印一次當前測試的進度信息。

-jitter：該選項必須與-rate同時使用，表示實際的訪問頻率會在rate設置的值上下隨機波動10%的幅度。

-checksum：由于要訪問某個url很多次，為了保證每次訪問時收到的服務器回包內容都一樣，可以采用checksum檢查，不一致會在屏幕上輸出錯誤信息。

-cipher：使用SSL層的時候會用到此參數（url是https開頭），使用特定的密碼集。

-timeout：設置超時時間，以秒為單位，默認為60秒。每超過一次則記為一次超時的連接

-proxy：設置web代理，格式為-proxy host:port

-throttle：限流模式，限制每秒收到的數據量，單位bytes/sec。該模式下默認限制為3360bytes/sec。

-sip：指定一個source ip文件，該文件每一行都是ip+port的形式。

需要特別說明的是，-parallel參數和-rate參數中必須有一個，用于指定發請求包的方式；-fetches和-seconds兩個參數必須有一個，用于指定程序的終止條件。

?

三、與webbench的對比

webbench是另外一款網頁性能測試工具，它的源碼分析可以參考如下連接：

http://www.cnblogs.com/xuning/p/3888699.html

webbench采用多進程發包，最多支持3萬并發量，而http_load采用單一進程并行復用方式發包。由于只有一個進程，http_load對于機器資源消耗較小，性能要求不高，但它的劣勢就是最大并發量比webbench要少許多，只能達到千的量級。在很多場景中，幾千的量級也已經綽綽有余了，因此具體工具的選用還要看實際情況。

我們分別使用webbench和http_load對同一個URL進行壓力訪問，結果如下。

?

[horstxu@vps ~/webbench-1.5]$ ./webbench -t 30 -c 1000 http://127.0.0.1:8080/user.pngWebbench - Simple Web Benchmark 1.5Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.Benchmarking: GET http://127.0.0.1:8080/user.png1000 clients, running 30 sec.Speed=180340 pages/min, 5268934 bytes/sec.Requests: 90170 susceed, 0 failed.[horstxu@vps ~/http_load-02aug2014]$ ./http_load -parallel 1000 -fetches 90000 url.txt 90000 fetches, 830 max parallel, 1.2933e+08 bytes, in 30.5439 seconds1437 mean bytes/connection2946.58 fetches/sec, 4.23424e+06 bytes/secmsecs/connect: 0.772754 mean, 215 max, 0.025 minmsecs/first-response: 17.2259 mean, 288.007 max, 1.735 minHTTP response codes:code 200 – 90000

?

如果進行一下換算，webbench測得的頁面RPS為180340 pages/min = 3006rps，這與http_load的測試結果2946fetches/sec結果是很接近的，并且，http_load統計數據更加全面，數據校驗也更加完善。對于每秒流量數據，webbench的結果是5268934bytes/sec，http_load是4234240bytes/sec。這其中的差別在于，http_load在統計時剔除了http報文的頭部（head），而webbench是沒有剔除頭部的。接下來我們來領略一下http_load的實現原理。

?

四、工作流程

程序的工作流程可以用下面這幅圖來表示，執行時程序主要環節位于流程圖中的循環內。http_load為單一進程的程序，因此進程內的所有調用都是非阻塞方式進行， 保證程序的流暢度。程序的執行過程主體在一個大循環當中，不間斷進行結束條件的判定和超時判定。時間管理方式是使用拉鏈式哈希表，超時情況下即運行超時處理函數。

?

五、原理分析

5.1 程序執行過程解析

如果使用簡化的代碼來描述上一節所述的流程圖，可以參考下圖。流程圖中的循環也就是主函數中的for循環。在主循環內主要做4件事情。首先，檢測當前程序是否滿足終止條件，如果滿足，則調用結束函數退出程序，否則進行下一步。然后，采用select監聽描述符狀態，一旦出現可讀或可寫狀態的描述符，則采用handle_connect與handle_read兩函數分別進行處理。需要提醒的是，源程序在處理讀取socket緩沖區這一段為了完美剔除掉http請求報文的頭部，耗費了大量的代碼。再然后，循環尾部執行超時檢測，檢查當前時間有沒有超過在哈希表中注冊的每一個時間戳，如果超過，則要執行其對應的超時處理函數。具體的時間戳管理方法見下文。源碼中共有5種時間戳需要注冊，分別對應著5個超時處理函數，請參考圖中的超時處理函數集合。

5.2 三個重要的結構體

下圖中詳細描述了三個源碼中最為重要的結構體。首先，程序采用全局變量connections數組控制每一個TCP連接，connections數組中每個元素都是一個指向connection結構體的指針。connection結構體包含了用于記錄測試數據的變量，連接狀態的控制變量，以及最開始從文件中讀取的連接配置信息。第二個結構體為url結構體，在http_load當中，想要請求的url存儲在文件內，可以大于一個。這些URL的信息會被讀取至由指向url結構體的指針組成的urls數組。請求會隨機發向這些數組。相比webbench，http_load的一個優勢是它的數據校驗環節。每一個url會配有返回請求的checksum值，用于校驗每次請求同一個url返回的內容是否一致。第三個結構體是時間管理方法中組成拉鏈式哈希表的每一個節點。它包含了指向超時處理函數的指針，以及記錄超時時間的變量。

5.3 時間戳管理方法

http_load中最為巧妙的就是它的時間管理方法。在該工具中，有很多需要定時觸發的地方，比如每隔一段時間輸出一份測試進度匯報；鏈接超過一定時間未響應則記為超時，輸出超時錯誤信息；設定發送頻率，每隔一段時間發出一個請求等等。這些時間戳和其超時觸發的函數以Timer結構體的形式，全部注冊于拉鏈法構成的哈希表中。每個鏈表都是以時間戳順序從早到晚依次排列。這樣，在每一個for循環執行超時檢測的部分，我們可以很方便地判斷出當前時間是否已經超過了時間戳的時間，如果超過，則執行超時處理函數。同時，這樣的數據結構也提高了插入新時間戳的效率。

?

六、結語

http_load與webbench都是很常用的壓測工具，如果配合使用，結果做對比，既是對測得結果的校驗，也能幫助熟悉兩種工具的優劣。http_load的設計思路也可以使用到業務測試工具中來，幫助開發出更高效的壓測工具。

總結

以上是生活随笔為你收集整理的web压测工具http_load原理分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。