高校統一身份認證系統集群壓力測試研究

文/馮興利 洪丹丹 羅軍鋒 鎖志海

隨著信息化建設的普及，各高校自主研發的信息管理系統越來越多，比如OA辦公自動化系統，為了鑒別登錄系統的用戶身份，身份認證系統不可或缺。統一身份認證系統使得用戶可以使用唯一的NetID登錄學校幾乎所有信息系統，避免了多個賬號帶來的混亂，也使得其他應用系統對用戶賬號的管理更加便捷。

西安交通大學統一身份認證系統（簡稱CAS）作為學校其他應用系統的統一認證入口，面向全部在校師生，主要為應用系統提供身份鑒別、用戶信息查詢等服務。目前，西安交通大學研究生管理系統、學生選課系統、本科教務管理系統等多個系統網站都使用基于統一身份認證平臺的單點登錄系統。只需登錄一次就可以訪問校內受統一身份認證保護的各項服務，為師生帶來了極大的便利[1]。截至目前，全校共有310個系統接入了統一身份認證平臺。

統一身份認證系統在給全校師生提供登錄便利的同時，也給自身服務器帶來了強大的壓力。為此，本文使用Loadrunner 11產生虛擬用戶（Virtual users）來模擬實際用戶對CAS系統施加壓力，進一步尋找系統的優化空間[2]。

Web性能指標

在Web應用程序的開發中，研發人員在保證項目如期完成的同時，也在關注著程序的性能和可靠性。優化Web應用程序需要參考資源使用情況、瀏覽器兼容性等多項性能指標。而在Loadrunner中，衡量Web前端性能通常使用以下三個指標：

1.事務響應時間

事務的響應時間是執行一個操作所需要花費的時間，一定程度上反映了服務器的處理速度。

業內流行的網站響應時間評價標準為：2秒之內被認為是“非常有吸引力”的用戶體驗；5秒之內被認為是“比較不錯”的用戶體驗；10秒之內被認為是“糟糕”的用戶體驗；超過10秒還沒有得到響應，那么大多數用戶會認為這次請求是失敗的[3]。

2.每秒點擊次數

每秒點擊次數是指用戶每秒向Web服務器提交的HTTP請求的個數，通過該項指標可以評估用戶產生的負載量。

3.吞吐量

吞吐量代表用戶每秒從服務器獲得的數據量，單位是字節。根據服務器的吞吐量可以評估服務器在Web流量方面的處理能力[4]。

集群測試環境配置

本次測試準備9臺虛擬機，其中一臺作為主控機，其他8臺作為負載機[5]。主控機上安裝完整版的Loadrunner 11，所有負載機上安裝負載發生器loadrunner generator，同時配置Loadrunner agent runtime settings configuration，所有虛擬機啟動loadrunner agent process。測試步驟如下：

1.采用HTML Based方式錄制腳本

在主控機上進行腳本的錄制，因網站采用HTTPS協議，故錄制腳本前需要對端口映射進行配置，并配置好客戶端指定的.pem格式的證書，之后即可開始錄制腳本[6]：打開統一身份認證登錄頁面，輸入賬號密碼，點擊登錄（事務login開始），登錄后返回登錄成功頁面（事務login結束）。錄制成功的腳本中包含了證書部分，如下：

對錄制好的腳本進行修改，將登錄用戶名和密碼參數化，并添加檢查點，保證所有用戶都能登錄成功，避免因部分用戶賬戶或密碼錯誤影響系統性能，同時對腳本中的參數JSESSIONID3進行關聯[7]。關聯方法如下：

2.配置測試場景

因每年的本科新生選課為統一身份認證并發量最多的一個階段，每年新入校學生為4600人左右，故本次測試最多模擬5000人并發登錄系統。

在主控機中模擬100,500,1000,……,5000個用戶同時并發登錄系統，要求瞬時并發，以完成登錄操作、返回登錄成功頁面為準。為了更好模擬用戶的使用習慣、節省時間和網絡帶寬資源，在進行場景配置時忽略Thinktime時間、出現錯誤仍繼續、不下載如js/css/圖片等非HTML資源、每次迭代不模擬新用戶、不清除緩存，以便測試結果更接近實際情況[4]。

3.連接主控機與負載機

在主控機的Loadrunner generator中添加8個負載機，并進行連接測試，連接就緒后即可進行負載測試。

測試結果與分析

本次測試分別模擬100,500,1000,……,5000個用戶同時并發登錄系統，以1000個用戶瞬時并發登錄系統為例，測試結果分析概要如圖1所示。

圖1顯示：1000個用戶并發登錄系統總計用時36s，平均響應時間為0.067s，平均每秒點擊次數未189.189次，平均吞吐量時962,027字節/秒，事務成功率為100%。90%的用戶登錄的平均響應時間在0.103s以下。由此可見，當1000個用戶并發登錄系統時，服務器的平均響應時間很短，響應用戶請求的速度極快。

圖1 1000個用戶同時登錄系統的測試結果

圖2 運行用戶數和平均事務響應時間關聯

圖3 吞吐量和每秒點擊次數

圖2為1000用戶并發登錄系統時，運行用戶數和平均事務響應時間的關聯圖，該圖能夠直觀地反映出一方的變化對另一方的影響。隨著運行用戶數的增加，理論上平均響應時間應該越來越長。但圖2顯然不是這樣，其原因在于：在并發測試的最后時刻，所有用戶同時執行一個事務，但由于各個用戶完成事務所用的時間長短不同，比較快完成事務的用戶，在完成之后就先退出了系統，在這種情況下，系統中運行的用戶數量越來越少，同時，由于這些用戶完成事務比較慢、所用時間較長，Loadrunner計算事務的平均響應時間也就長了，所以就出現了圖2中用戶越少事務響應時間反而越長的情況。

圖3是1000個用戶并發登錄系統時，吞吐量和每秒點擊次數的疊加圖。由于每秒點擊次數反映了客戶端每秒向服務器提交的請求數量。客戶端發出的請求越多，服務器的吞吐量也應該越大，正常情況下，兩者應該是一一對應成正比的關系。圖3正好反映出這種關系，表明服務器能夠及時準確處理客戶端的請求。

上述是對1000個用戶并發測試進行詳細分析，接下來將對50,100，……，1000個用戶并發測試的平均響應時間、平均每秒點擊次數、平均吞吐量三個指標進行匯總和分析。

1. 平均響應時間

圖4顯示并發用戶數與平均響應時間的關系，最佳性能的服務器其平均響應時間隨著并發數的增加變得比較平緩。可以清晰看到，隨著并發用戶數的增加，平均響應時間增幅基本不變，表明系統的處理能力并沒有隨著并發用戶數的增加而下降，非常穩定，未受到并發數增加的影響。且當并發用戶數為5000時，平均響應時間為0.063s，用戶體驗非常好。

圖4 并發用戶數與平均響應時間

圖5 并發用戶數與平均每秒點擊次數

圖6 并發用戶數與平均吞吐量

2. 平均每秒點擊次數

圖5表示并發用戶數與平均每秒點擊次數的關系。最佳性能的服務器每秒處理請求的個數是隨著并發數的增加而增加的[8]。圖中可以直觀看到：服務器處理請求的個數隨著并發數的增加有上升趨勢，說明服務器處理能力不錯，響應速度沒有變慢，能夠及時處理用戶提交的HTTP請求。

3. 平均吞吐量

圖6為并發用戶數與平均吞吐量的關系。吞吐量即服務器每秒接受到的數據流量。理想狀態下，服務器接受到的數據流量一定是隨著并發數的增加而上升的[9]。該圖清晰的表明當并發數增加的同時服務器接受的數據流量存在上升趨勢。

圖5和圖6兩條曲線走向基本一致，說明服務器能及時接受客戶端提交的HTTP請求，并能正確返回請求結果[10]。

通過本次測試可看到，西安交通大學統一身份認證系統服務器完全可以承受5000個用戶的并發登錄。一般情況下，用戶并發數相當于實際用戶數的四分之一，即5000個用戶同時并發登錄系統，相當于20000個用戶同時系統在線[11]。本次測試表明服務器完全可以承受20000個用戶系統在線。由平均響應時間、平均吞吐量、平均每秒點擊次數等軟件性能指標可直觀的看出網絡性能非常優秀，客觀地反映出服務器處理能力很好。有關服務器CPU、內存等硬件資源的監控，還需要在后續的測試中進一步監測分析。