一、前言
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.png Webbench - Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://127.0.0.1:8080/user.png 1000 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 seconds 1437 mean bytes/connection 2946.58 fetches/sec, 4.23424e+06 bytes/sec msecs/connect: 0.772754 mean, 215 max, 0.025 min msecs/first-response: 17.2259 mean, 288.007 max, 1.735 min HTTP 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的設計思路也可以使用到業務測試工具中來，幫助開發出更高效的壓測工具。