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

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

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

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

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

{

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

if ( pid < 0 ) exit(0);

}

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

{

child_process();

}

if ( pid )                              //父進程代碼

{           

…

}

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