性能測試工具之研究

【關鍵詞】 性能測試、 Vugen 、 Conductor 、 Player 、 Analysis

•  性能測試的意義

追求更高的質量和更高的性能是人類的天性。 “ 更高，更快，更強 ” 的奧運會是對人類自身運動能力的測試。同樣，人類也在追求我們工作生活中不可或缺的 IT 系統能夠提供更快更強的服務。目前 IT 系統已經稱為各個企業運轉業務時最重要的系統之一。對 IT 歷史稍微有所了解的人都知道， IT 系統經過早年的一個人使用的單機系統時代，幾十個人使用的局域網中的客戶機服務器系統時代，到現在服務成千上萬用戶的跨廣域網的龐大系統時代。 IT 系統發展中的最明顯的特征之一就是所謂的 “ 數據大集中 ” ，即數據越來越集中到后臺的服務器中，系統同時為成百上千，乃至上萬的用戶提供服務。這樣的例子在銀行、保險、電信公司中隨處可見。隨著企業業務量的加大，其 IT 系統承載的負荷越來越重，系統性能的好壞嚴重影響了企業對外提供服務的質量。對 IT 系統的性能進行測試和調優越來越引起企業的重視。

目前，典型的企業 IT 系統的架構如下所示：

這樣的系統由客戶端、網絡、防火墻、負載均衡器、 Web 服務器、應用服務器 ( 中間件 ) 、數據庫等等環節組成，根據木桶原理，即木桶所能裝的水的量取決于最短的那塊木板，整個系統的性能要得到提高，每個環節的性能都需要優化。在這樣的 IT 系統中，每個環節的都是一個很復雜的子系統，對其調優都是一門專門的技能。 Oracle 數據庫的調優就需要專門的技能和多年的經驗。對于整個 IT 系統的調優，其復雜程度更是急劇增加。因此 IT 系統性能測試調優是一個復雜的項目，需要擁有各種專門技能的專家組成小組來完成。這些專家包括操作系統專家、網絡專家、數據庫專家、應用服務器專家、應用軟件和業務專家等等。

雖然性能測試是一項很復雜和專業的工作，但是由于企業 IT 系統的重要性，保證其性能的穩定對于企業對外提供優質服務越來越得到企業的重視。性能測試服務的市場正在快速發育中。研究系統性能測試越來越有意義。

要保證性能測試項目的高質量，必需依賴兩個重要的因素：人和工具。具有多年經驗的高素質的專家小組是保證性能測試的最重要的因素。另一方面，功能全面、使用靈活的性能測試工具對于加速性能測試，提高測試質量和效果也是必不可少的。

現在有很多種性能測試工具，從功能簡單單一的開放源碼的軟件到昂貴的商業性能測試工具。本文論述了性能測試工具的一般體系架構和技術要點，并探討了利用已經存在的開放源碼的軟件整合出一套開源的優質的性能測試工具的可行性。

•  性能測試工具綜述

性能測試的主要手段是通過產生模擬真實業務的壓力對被測系統進行加壓，研究被測系統在不同壓力情況下的表現，找出其潛在的瓶頸。因此，一個良好的性能測試工具必需能做到以下幾點：

•  提供產生壓力的手段

•  能夠對后臺系統進行監控

•  對壓力數據能夠進行分析，快速找出被測系統的瓶頸。

產生壓力的手段，主要是通過編寫壓力腳本，這些腳本以多個進程或者線程的形式在客戶端進行運行，來模擬多用戶對被測系統的并發訪問，以此達到產生壓力的目的。由于一臺普通的 PC 機可以輕易產生幾百乃至上千個進程或線程，通過使用若干臺 PC 機，就可以輕易模擬出成千上萬個并發用戶。壓力腳本執行的功能和被測系統客戶端軟件執行的功能應該一樣，從而產生真正的業務壓力。 編寫壓力腳本的工作實際上就是重新編寫客戶端軟件。為了快速達到編寫腳本的目的，采用的最有效的方式是通過性能測試工具錄制客戶端軟件和服務器之間的通訊包，自動產生腳本，然后在自動生成的腳本的基礎上進行少量修改，如：關聯動態內容，指定批量測試數據等。根據經驗，壓力腳本的準備工作往往占據整個性能測試項目的 50% 的時間和工作量。 因此，能否提供錄制和自動產生腳本的功能是性能測試工具最主要的評價指標之一。

壓力腳本的方式給我們提供了模擬各種壓力狀況的有力手段，通過人為制造各種類型的壓力，我們可以觀察被測系統在各種壓力狀況下的表現，從而定位系統瓶頸，作為系統調優的基礎。因此，提供豐富的對后臺系統進行監控的手段是性能測試工具第二個最主要的評價指標。監控應該不在被測系統上安裝任何軟件，否則的話，為了監控而引入的 “ 代理 ” 之類的小軟件將給被測系統引入新的可變因素，一方面造成了測試結果的不準確，另一方面會給用戶的系統的穩定性可能造成影響，從而導致用戶的反感和拒絕。目前，各種監控手段大都采用所謂 “ 無代理 ” 的方式，即不在被測系統上安裝任何軟件，僅僅通過改變被測系統的配置，就可以對被測系統進行監控。需要監控的部件多種多樣，包括操作系統、數據庫、中間件、應用系統、安全模塊、網絡、防火墻等等。

一組壓力測試運行完畢后，我們會得到詳盡的性能數據。這些數據包括最終用戶的響應時間，后臺系統各個部件的運行數據。這些數據的量非常大，往往包括幾千個變量的運行曲線，大小可能達到上 G 的規模�？咳斯とシ治鲞@些數據幾乎是不可能的，性能測試工具必需提供數據分析工具，幫助性能測試人員去閱讀、解讀和分析數據，輔助測試人員定位系統的瓶頸。數據分析工具是保證最終測試成果的手段，因此它是性能測試工具中最重要的部分之一。

目前已經存在的性能測試工具林林總總，數量不下一百種，從單一的開放源碼的免費小工具如 Aapache 自帶的 web 性能測試工具 ab 到大而全的商業性能測試軟件如 Mercury 的 LoadRunner 等等。任何性能測試工具都有其優缺點，我們可以根據實際情況挑選用最合適的工具。

前面已經指出，性能測試是一項復雜的工作，一個性能測試項目的質量如何，測試人員的素質、能力和經驗是最關鍵的因素。擁有世界上最先進的 CT 掃描儀并不能讓你成為一個優秀的醫生。不過， “ 工欲善其事，必先利其器 ” ， 擁有一套自己非常熟悉，功能全面、質量可靠的性能測試工具對于從事性能測試的人員非常有吸引力。在商業性能測試軟件中，大多價格非常昂貴。由于大多數性能測試工具是按照并發用戶數收取費用，因此要獲得大的并發量的價格是很高的。雖然存在很多免費的性能測試工具，但其功能不足，彼此不成系統，不能靈活搭配使用。

一套功能全面的性能測試工具的開發工作量是非常大的，這也是為什么商業性能測試軟件價格昂貴的主要因素之一。由于互聯網和開放源碼運動的發展，性能測試工具的各種功能都以各種形式的開源軟件存在了。 如果我們設計出一套合理的架構，在統一的架構下整合各種缺乏系統性的開源工具軟件，使之能夠彼此配套，搭配出一套功能全面、質量可靠，而且是開放源碼的性能測試工具是完全有可能的。

本文的下面部分具體論述性能測試工具的基本框架和技術要點，希望熱愛編程，希望對開放源碼運動有所貢獻的讀者能從本文的論述中獲得一些啟發，沿著作者的思路繼續往前行。

•  性能測試工具的體系架構

作者對性能測試工具 LoadRunner 比較熟悉，通過對 LoadRunner 的了解和評估，作者設計的性能測試工具體系架構如下圖所示：

性能測試工具的組成部分有如下幾個：

•  虛擬用戶腳本產生器 Vugen(Virtual User Generator)

•  壓力調度和監控系統 Conductor

•  壓力產生器 Player

•  壓力結果分析工具 Analysis

通常，進行性能測試項目的一般步驟如下：

•  用戶確定需要錄制的交易，通過用戶操作和 Vugen 的錄制，記錄并生成自動化腳本。

•  修改腳本，確定腳本能夠回放成功。

•  Conductor 是一個集中控制平臺，它和壓力產生器 player 互連，指定腳本在 player 上的分配，并控制 player 向被測系統的加壓方式和行為。

•  Conductor 同時負責搜集被測系統的各個環節的性能數據。各個 Player 會記錄最終用戶響應時間和腳本執行的日志。

•  壓力運行結束以后， Player 將數據傳送到 Conductor 中， Conductor 負責將數據匯總。

•  數據分析工具 Analysis 讀取壓力測試數據，進行分析工作，確定瓶頸和調優方法。

•  針對性地進行系統調優，重復進行壓力測試，確定性能是否得到提高。

•  重復以上 3-7 步，逐步提高系統的性能。

魯制腳本的工具虛擬用戶產生器 Vugen 實際上是一套開發調試工具。 Conductor 是一個框架程序和監控程序，它負責將 Vugen 開發的腳本以多進程 / 多線程的方式在 Player 機器上運行。為了產生更大的壓力， Conductor 必需支持集群功能，理論上 Conductor 可以和任意多臺 Player 機器互連，以便產生足夠大的負載壓力。 Conductor 同時實現無代理方式的監控功能，可以監控各種主流的軟件，并且提供對不支持的軟件進行監控的二次開發的手段。 Analysis 實際上是一個數據分析工具，用于事后的數據分析，它可以安裝在任何 Windows 平臺的機器上。下面我們論述每個部件的技術要點。

•  虛擬用戶產生器 Vugen

虛擬用戶產生器通過錄制客戶端和后臺服務器之間的通訊包，分析其中的協議，自動產生腳本。用戶在自動產生的腳本的基礎上進行修改，從而快速開發出一個邏輯功能和客戶端軟件完全一樣的壓力腳本程序。

錄制的技術主要是通過 proxy 的方式來實現的，如下圖所示：  

Vugen 根據對捕獲的數據的分析，將其還原成對應協議的 API 組成的腳本。由于 Proxy 源程序的獲得非常容易， Vugen 的主要的技術要點是 如何根據捕獲的數據包來反解析成對應的網絡協議 。通常捕獲的數據包為 TCP 數據流，我們可以很容易的生成 socket 層次的腳本，類似如下示例：

int main( int argc, char** argv)

{

char buf[BUF_MAX_LEN];

int socket = 0;

socket = connect(“IP=192.168.52.65”, “Port=3200”, TCP);

getbuffer(buf, “trace.dat”, 1, SEND);

send(socket, buf);

receive(socket, buf);

getbuffer(buf, “trace.dat”, 3, SEND);

send(socket, buf);

receive(socket, buf);

……

close(socket);

}

其中 trace.dat 包含著錄制時捕獲的數據包，按照 “ 發 - 收 - 發 - 收 - 發 - 收 ” 的順序排放。

毫無疑問，這樣的腳本按照記錄的收發過程來回放，但是它的最大的缺點是處于太底層。要分析和修改 socket API 的腳本以及數據包的具體內容將是一個繁重而且煩人的工作，進行關聯的工作的難度也將大大提高�？蛻舳顺绦蛲�往是利用更高層的應用協議 API 編寫的，客戶端軟件的編寫者也不一定對 socket-API 組成腳本進行修改。因此， Vugen 應該盡可能地產生更高層網絡協議的腳本 ，方便用戶的閱讀和修改工作。

以 Tuxedo 應用為例，對于 Tuxedo 應用，一次典型的 Tuxedo 業務調用的序列為：

tpinit(….) // 和后臺建立連接

tpcall(….) // 向后臺發起交易請求

tpterm(…) // 斷開和后臺的連接

這三次 api 調用將產生 TCP 層的 7 次收發動作， Vugen 必需根據這 7 次的收發，還原產生 Tuxedo-API 的調用序列。

由于對于不同的應用層協議，只能分別開發，因此， Vugen 支持的網絡協議的多少是衡量性能測試工具的主要指標之一。

當然， socket 方式是一切應用層協議的基礎， socket 腳本是一種通用的方式。對于 Vugen 不支持的應用層協議只能通過 socket 層次來錄制。因此 Vugen 能生成 socket-API 腳本是其最基本的功能。

VuGen 產生的腳本應該應該是跨平臺的，因此它應該提供 C/Java 兩種語言的方式，支持各種平臺的 C/Java 編譯器。腳本可以在 Windows/Unix/Linux 上運行， Player 運行的機器既可以是 Windows 平臺，也可以是 Linux, FreeBSD, Solaris, AIX 和 HP-UX 等平臺，這樣會方便用戶選擇機器作為 Player 。這一點非常重要。

由于 Vugen 支持的每種應用層協議必需單獨開發，在設計 VuGen 的軟件體系架構時，應該采用插件的方式來設計網絡協議的解析器。這部分的設計借鑒了 Apache 的 module 設計思想，可以讓任何對開發協議解析器感興趣的開發者在一個統一的框架下開發。

VuGen 的體系結構如下圖所示：

Vugen 的體系結構分為三部分：

•  第一部分為底層 proxy 錄制器 , 負責捕獲客戶端和服務器之間通訊的數據包，這樣的軟件在開放源碼的世界里面隨處可見，而且非常成熟。 我們只要移植過來就可以使用。

•  第二部分是界面部分，提供腳本編輯、調試和運行功能，這部分可以用 Visual C++/MFC 實現 Windows 平臺版本和 Java/AWT 實現 Unix 版本。

•  第三部分是以插件的形式提供的分析各種網絡協議的解析器。開發這類插件的強有力的開發工具為 lex 和 yacc 。

•  Proxy 二次捕獲的問題

Vugen 的 Proxy 方式需要解決的一個問題是二次捕獲數據包的問題。

早期的網絡服務器程序對外提供一個固定端口，客戶端僅僅和這個端口通訊就可以了。這對于 proxy 錄制非常容易。但是現在很多服務器程序為了提高對客戶端并發量的支持，采用兩個端口通訊的方式。如下圖所示：

整個通訊的過程如下：

•  第一步：客戶端將請求發往 Proxy 錄制器。

•  第二步： Proxy 錄制器將請求發往真正的服務器的指定端口，即圖中的 3200 端口。

•  第三步：服務器機器的 3200 端口返回數據包給 Proxy 錄制器。該數據包中包含了下一次通訊的目的地址，形式為 IP:Port 。很顯然，這里的 IP 數據為真正服務器的 IP 地址。

•  第四步， Proxy 錄制器把請求返回給客戶端。

•  第五步，客戶端根據提供的 IP:Port 信息直接把請求發往真正的服務器，不再經過 Proxy 錄制器。

•  第六步：以后的通訊只是客戶端和服務器之間的通訊了， Proxy 錄制器是無法捕獲這些通訊包了。

因此一般的 Proxy 錄制器只能捕獲頭兩個收發的數據包。 這個問題更一般的情形的例子是 HTTP 的 redirection 功能。第二次通訊可能發往另外一臺機器了。 Proxy 錄制器必需解決這個問題。

•  關聯的問題

客戶端和服務器之間的通訊，有一部分是數據是動態的，每次通訊都不一樣。 Proxy 錄制器在錄制的時候是無法區分哪些是靜態的信息，哪些是動態的信息，所有的信息都以 hard-coded 的方式記錄下來。但是在回放的時候，如果有些信息不改變，那么腳本是不能執行成功的�？紤]如下情形：

如上圖所示，用戶 jojo 以 jojo/bean 的賬號 / 口令登錄某一 web 服務器，查詢某產品的信息，由 Vugen 錄制交易的全部通訊包。 web 服務器返回給 jojo 一個動態的會話 ID: SessionID@12345 ，作為這次登錄的會話標識。由于 Vugen 無法知道哪些信息是動態的，它會照單全收的方式，把所有的數據就記錄下來。接著 jojo 根據 Web 服務器告訴他的 SessionID 去查詢產品列表，交易可以正常執行下去。

我們會觀察到，當 Vugen 根據捕獲的通訊包生成 http 腳本的時候， SessionID 是 Hard-coded 的，即 “ 寫死 ” 在程序里面的。當我們不加修改的回放該腳本的時候，會出現什么問題呢？如下圖所示：  

按照錄制時候的腳本， jojo 以 jojo/bean 登錄后， Web 服務器返回給 jojo 一個動態會話 ID: SessionID@23456 ，這個值已經不是錄制時候產生的 SessionID@12345 了，而是新的值： SessionID@23456 。那么腳本根據記錄的 SessionID 的值，仍然會使用 SessionID@12345 去執行下面的查詢交易。由于會話 ID 是有時效性的，用戶退出系統后，其 SessionID 會失效，那么，服務器會給出一個 “SessionID 失效 ” 的錯誤，從而導致腳本無法正常執行下去。

對于上面的問題的通用解決方法如下圖所示：

在第一次從服務器得到 SessionID 的時候把其放在一個變量 <session_id> 里面，在后面腳本訪問服務器的語句里面，把所有的 ”SessionID@12345” 替換為變量 <session_id> 就可以圓滿解決這個問題。

這種問題在任何系統都是非常常見對外問題。其通用的模式是： “服務器返回給客戶端一些動態變化的值，客戶端使用這些值去訪問服務器的時候，不能把這些值寫死在腳本里面，而應該存放在一個變量里面�！� 這就是關聯的概念。

關聯的工作往往占據開發腳本的大部分時間，因為我們必需針對每一個具體的系統進行細致的分析，確定其需要關聯的動態信息。為了快速開發腳本， Vugen 必需提供幫助我們關聯的手段，最好做到自動關聯。自動關聯的方法有三種：

•  在錄制之前設定辨別規則，錄制完畢，產生腳本的時候根據規則識別出需要關聯的動態內容，從而產生正確的腳本。

•  錄制完畢回放一遍，把回放結果與錄制結果進行自動對比，確定動態信息，進行自動關聯。

•  錄制兩個一模一樣的腳本，對比其中的差異來確定需要關聯的動態信息，然后進行關聯。

自動關聯的功能是否完整可靠，關系到我們能否借助 Vugen 快速開發出符合要求的腳本，因此關聯也是 Vugen 中非常重要的功能。

•  腳本的問題

Vugen 產生的最終結果是以源程序方式存在的腳本。為了編譯該腳本，用戶可以選用對應的編譯器，這不是 Vugen 的功能。建議 Vugen 產生腳本的時候應該生成對應的 Makefile 和 build.xml ，允許用戶以流行的 make 和 ant 命令來編譯 C 和 Java 的腳本。關于 make 和 ant ，讀者可以在互聯網上查詢相應的內容。

Vugen 自動產生的腳本應該支持兩種語言， C / Java 。很顯然， Vugen 不可能產生一個腳本運行的全部的代碼，它需要額外的函數庫的支持。譬如，通過錄制 Tuxedo 協議產生的腳本應該是以 Tuxedo-API 的形式出現的。為了能夠編譯運行腳本，必需把 Tuxedo 的函數庫連接到腳本里面。目前動態庫的技術應用非常廣泛，因此為了運行 Tuxedo 腳本，必需在 Vugen 和 Player 機器上安裝相應的 Tuxedo 客戶端軟件，因為它包含相應操作。其它網絡協議也存在這個問題。對于 http 協議，已經有很多函數庫。 Vugen 產生的 http 腳本應該支持主流的函數庫。這樣帶來的好處是我們不需要自己開發 http 函數庫，可以直接引用已經經過實踐證明了的質量可靠的函數庫。選擇支持何種函數庫，需要慎重選擇，我們應該選擇應用最廣泛的函數庫。例如：關于 http 函數庫，可以采用 www.w3c.org 提供的 libwww ，該函數庫是開源的，質量可靠，遠勝于我們自己開發。

•  Conductor 和 Player 部分

Conductor ，我們稱為 “ 指揮家 ” ，它是整個壓力測試的核心。 Player 是產生壓力的負載產生器，它們以進程或者線程的方式運行由 Vugen 生成腳本。 Player 如何運行腳本，由 Conductor 來決定。這好比一個交響樂隊在演奏。 Player 就是各種管弦樂演奏者， Conductor 是指揮者。

Conductor 和 Player 實際上是一套框架程序。具體執行什么功能，是由腳本來完成的。 Conductor 和 Player 的體系結構如下圖所示：

如上圖所示， Conductor 上面有若干進程 / 線程。每種進程的作用如下：

•  Center 進程是整個調度的核心進程，它負責聯系和用戶界面打交道的工作。

•  Agent 進程負責和遠端的 Player 機器中對應的 Agent 進程通訊。負責把編譯好的腳本傳送到 Player 機器上。在腳本運行的時候，定期從 Player 機器上獲取 Player 的運行狀態，每個虛擬用戶運行的日志。

•  Monitor 進程負責對被測試系統的各個環節進行監控，并把監控的內容一方面寫入 Conductor 機器的本地磁盤，另外一方面把監控的內容傳送給 Center 進程，實時地顯示在用戶界面上。

Player 的進程有兩種，一個是 Agent 進程，一個是 Player 進程。 Agent 負責和 Conductor 機器通訊，它根據 Conductor 的指示，在本機器上派生出指定數目的 Player 進程，這些 Player 進程負責具體執行相應的腳本。 Player 進程個數就是虛擬用戶的個數。

Player 需要解決的一個問題是 IP 問題。為了防止黑客的攻擊，某些后臺的負載均衡設備一旦發現來自某一個 IP 的請求特別頻繁時，就會拒絕為該 IP 提供服務。這樣的功能造成的結果是 Player 無法把真正的壓力加到后臺系統中。解決方法就是在 Player 機器上偽裝多個 IP 地址發送請求。這項技術稱為 IP 欺騙 (IP Spoofling) 。 Conductor 和 Player 必需實現該項功能。

•  Conductor 和 Player 的技術要點

關于 Conductor 和 Player 的技術要點有哪些，目前我還沒有做深入的研究工作，但是我認為其技術要點主要涉及多進程 / 線程的編程，網絡編程技術�？赡苓@里面最大的難點是監控問題。當把被測系統的各個環節都監控起來，需要監控的參數會有成百上千個。如果采用集中式監控的方式，采集數據本身就對系統造成很大的影響，所以必需支持分布式監控方式。由于采集的數據是來自不同機器上的，由于各種的延遲，數據之間的時間同步將是一個重大的問題。

關于監控，還需要進一步的研究。

由于 Player 是沒有界面的，是后臺運行的程序，為了保持其可移植性，建議采用 Java 語言開發。

Player 和 Conductor 之間的網絡協議不一定重新開發，可以使用成熟的 Http 1.1 ，方便在性能測試時調試 Player 和 Conductor 之間可能出現的通訊問題。

•  數據分析工具 Analysis

該工具是一個純數學工具軟件，目前市場上已經存在了大量負責數據處理的軟件，如 Matlab 等�？梢詫�壓力產生的數據直接導入其中進行處理。所以只要提供開放的數據接口就可以了，無需自己開發獨立的性能數據分析軟件。

即使 Analysis 需要開發，應該開發一些知識分析的功能。譬如，我們搜集了很多 Oracle 的數據信息，這些數據之間往往有固定的聯系。如果將這些聯系的知識融入到 Analysis 當中，將會更好。但是這有點類似人工智能的意味，比較難。

•  結束語

本文是對性能測試工具的一般性論述，討論了性能測試工具的基本功能和可能出現的技術要點。由于性能測試工具涉及的內容太多，作者只是大致論述。其中涉及細節當中仍然會有很多技術要點沒有論述。只是希望本文對希望了解性能測試工具的讀者有一個入門的幫助。

一套功能全面的性能測試工具就象水管工經常攜帶的工具箱，里面充滿各種工具，這些工具經過組合可以完成任何復雜的機械工作。完全從頭開發這套工具箱，工程浩大，靠業余的編程愛好者是很難完成的。但是我們應該吸取 Unix“ 小而靈活 ” 的哲學思想，在一個大的框架下面開發或者利用已經存在的開源工具軟件制造出一個個靈活的部件。當把這些部件組合起來以后，就是一個功能完整、質量可靠的性能測試工具箱。