TUXEDO作為一種成熟的事務處理中間件，一般用于大型系統的業務處理。在這樣的系統中，一般客戶端請求的并發數很大，而且對實時性要求很高，需要在規定的時間內處理完一個事務，并返回結果給用戶。而且對系統的穩定性要求也很高，一般都要求7x24運作。為滿足以上要求，除了系統各部分有良好的設計、編碼和測試外，還需要在上線前對系統的處理能力、極限容量等做一個測試和評估，以便獲得關于系統的更真實的性能情況。這種測試是從外部來觀察系統的整體情況，比起某個部分的性能評比更有實際的意義，而且使得項目開發人員和以后的運行維護人員對系統的整體性能有一個具體的認識，便于調整和日后的維護。

接下來筆者以自己參與開發的一個大型電信項目為依托，結合自己設計和實現的TUXEDO服務器壓力測試工具來分析一下壓力測試中的一些方法和過程，以及要注意的問題。

壓力測試必須有一定數量的并發客戶端。為了測試，準備大量的PC，并在每一個上裝一個client程序是不現實的，而且難以做到真正的并發，也不利于客戶端數目不斷變動的大量的測試，因此我們采用了軟件模擬客戶端的方法。對TUXEDO服務器而言，每一個客戶端就是一個和它通信的進程，所以需要多少客戶端簡單的說就是開多少調用服務的進程，這個在OS的支持下是很容易實現的。這里有一個問題需要討論，一般會想到用一個現成的壓力測試軟件來做。實際中發現，這種方式是有問題的。一般壓力測試工具的方法是截獲一個client到server的調用數據包，分析其中的數據，然后將一些數據進行參數化，例如一些ID等，然后生成一個可以產生大量并發的同類數據包的腳本，運行該腳本就可以進行壓力測試，當然其中包括了很多度量。對于某些應用，例如新開戶等，這種方法可以工作得很好，但是對于那些對數據真實性要求很高的服務，這種方法就難以實現。例如筆者做的壓力測試中涉及的主要TUXEDO服務——用戶帳單的查詢和銷帳處理。由于用戶的電話號碼或者帳號等通常是不連續的，中間有很多的空洞，而且銷帳的服務是依賴于查詢的返回結果的，如果不是數據庫中一條真實的可以做銷帳處理的帳單是不能成功的完成銷帳流程的。這對構造數據帶來很大的難度，而且那種構造出來的數據和實際的情況會有很大的差距，因為那可能被數據庫的緩沖等進行優化，不能反映真實的性能，而最好的辦法當然是用實際數據庫中的真實數據。當然，這種真實也可以有一定的擴充，下面會涉及到關于壓力測試數據的準備問題。通過上面的討論，我們知道在一些實際的系統中，讓了解系統應用的人自己動手來做壓力測試很多時候是一個更好的選擇。不必擔心這個工作的復雜性，下面我們就相關的問題開始詳細的分析。

1．模擬出指定數目的客戶端。
    開多進程需要OS的支持，下面以UNIX為例給出了一個實現的代碼。需要特別注意的是后面注釋有*的那一行代碼，該行的意義是在子進程(pid=0，fork對父進程和子進程有不同返回，參考[1])中不再執行該循環。在UNIX中，子進程從fork()的下一句開始執行。如果沒有上面那一句，新開出的子進程發現滿足for循環的條件將繼續執行循環，開出新的它自己的子進程，這樣會產生復雜的進程樹，可以計算那樣得出的子進程的數目為。為更好的控制客戶端的數量和保持進程相互關系的簡明，我們通過上面那一句使得進程的關系只有兩層，而且進程數目就等于P_NUM。

for ( i = 0; i < P_NUM; i++ )        //P_NUM為要開的進程數，也就是模擬客戶端的數目

{

if ( (pid = fork()) == 0 ) break;            //*

if ( pid < 0 ) exit(0);

}

if ( pid == 0 )                       //子進程代碼

{

child_process();

}

if ( pid )                              //父進程代碼

{           

…

}

通過上面的代碼，我們對客戶端的產生有了清楚的認識，在進程創建后，父、子進程分道揚鑣，開始各自的壓力測試之旅。