負載測試應該是每項 Web 開發工作的一部分，並且應在開發過程的早期進行。然而，如果您認爲可以利用開發環境進行負載測試，那麼當您發佈應用程序時多少會感到驚訝。在本文中，作者將對規劃負載測試工作、考慮使用哪些計算機、模擬用戶的數量、適用的工具以及如何解釋結果這一過程進行概述。
讓我們設想以下場景。您即將結束爲期 6 個月的對某項複雜的 Internet 應用程序或 Web 服務的開發工作，並且已準備對其進行部署。開發團隊小心翼翼地就鬆散耦合的n層 Web 應用程序進行了設計。從工作的第一天開始，所有可伸縮、穩定的和高性能的應用程序所必需的要素就已悉數構建到系統的體系結構之中。質量保證團隊已對系統進行了徹底地測試、解決掉了大部分的嚴重錯誤並仔細考慮了那些待發現的剩餘錯誤。因此，您的開發工作應該進行得相當順利，對嗎?請再想一下。
您已將負載測試作爲開發工作的一部分進行實施了嗎?如果沒有，那麼您應接受這樣的事實：即，在複雜的設計當中，您將需要就某些地方的性能、可伸縮性和可靠性方面予以關注。瓶頸是系統中阻礙正常通信量流量的元素。儘管良好的設計對於構建成功的 Web 應用程序而言至關重要，但是經驗告訴我們，大部分這些種類的錯誤只能在系統處於較大負載的情況下才會被發現。這些是您作爲單個用戶在開發過程期間，通過測試系統無法發現的問題。儘早地實施負載測試計劃有助於確保將在開發時出現的意外情況降至最低限度。
在本文中，我們將介紹基於實際經驗的測試方法，但這並非拋開傳統的負載測試策略。由於帶領過衆多的負載測試團隊，我們汲取了一些教訓，它們可能會對您有所幫助。
我們將討論較早開始測試工作的優點，並概述設置測試環境的注意事項。我們將幫助您確定適於自己的實現的度量標準，並介紹一些實施這些度量標準的工具。此外，我們將向您說明，爲什麼“我的站點能同時處理x名用戶嗎?”這樣的問題太過含糊而無法精確回答。最後，我們將討論一些針對您的特定需要選擇適當的負載測試工具的重要注意事項，並對跟蹤測試結果提出一些建議。
我們將使用術語“負載測試”來描述性能、可伸縮性和可靠性測試。人們往往過於頻繁地使用術語“可伸縮性測試”來描述上述這三項，而您的團隊所做的很可能不僅限於此。圖 1描述了這些目標。
儘早開始
您應在設計階段就開始規劃負載測試工作。根據我們的經驗，建議您採取“無驚訝”方法來進行開發工作。工作時始終抱着會發現問題的想法。分佈式 Web 應用程序和 Web 服務的體系結構日趨複雜，使得潛在問題成爲應用程序設計中的固有現象。
最近，我們在複雜的n層 Web 體系結構的開發階段中，進行的負載測試效果不錯。但我們對其中的兩個問題估計不足。第一，我們低估了測試開始後將會發現的問題數量。我們的第一次測試運行在只處理了 2 名用戶和 100 份定單後就告失敗了。第二，我們低估了設置測試環境所需要的時間。幸運的是，由於我們開始規劃測試足夠早，從而有時間解決在部署日期之前發現的問題，或將問題降到最少。通過密切關注設計，成功地解決最初的幾個問題後，系統的可伸縮性很快就得到了提高。
通過定義測試環境，您就可以開始規劃測試工作。根據測試工作的規模，這可能是很重要的任務。
定義環境
在定義測試環境的過程中，第一個任務就是估計需要何種工作。我們用於資源成本的一條通用指南是，將實現時間的 15% 至 20% 用於測試，其中的大約三分之一用於負載測試。
重要的是創建單獨的測試環境，該環境應與生產環境類似。如果計算機的配置、速度和設置均不相同，那麼要推斷出生產環境中的性能幾乎是不可能。換言之，對於諸如“向系統添加更多硬件是否能提高可伸縮性”這樣的問題，您能給出確定回答，但是對於“在生產環境中一臺 Web 服務器能處理多少用戶?”之類的問題，您卻無法準確回答。您的主要任務之一就是降低不確定性，並通過結論性的證據來回答問題。如果沒有類似的硬件，在迫不得已的情況下，您充其量也只能根據經驗進行猜測。
面對將生產用計算機用於負載測試環境的成本，您可能會畏縮不前。但請您考慮考慮在生產環境中查找與硬件相關的問題所需的成本，以及精確預測單臺 Web 服務器能處理的負載的價值。諸如處理器速度和可用的 RAM 之類的變量會影響可用系統資源，並隨之可能更改可伸縮性問題表明它們自身的方式。在實驗室中，環境變量是不可抗拒的因素。該種變量數量太多，而您無法確定問題的根源。如果不可能使用單獨的環境，那麼請考慮加速生產硬件購買以用於負載測試實驗室中。一旦部署了系統，實驗室設備就還可以用作生產設備的備用品。另一個好處是，用不着等到發佈之日前，您就能消除系統缺陷。
關於爲何您不應使用開發環境進行測試，有幾點原因。有關詳細信息，請參閱提要欄“Dont Use Your Dev Environment for Load Testing”。對於質量保證團隊所使用的系統測試環境，情況亦是如此。這適用於想要跟蹤似乎與系統負載無關的功能錯誤的單個用戶測試。這種測試對系統測試環境中使用的硬件類型放寬了限制。它從開發團隊接收的軟件更新也更頻繁。在負載測試中，應只安裝影響系統性能的版本，以將修改負載腳本的耗時縮至最短。
除了可伸縮性實驗室運轉所必需的資源以外，負載測試工作是否能成功還取決於組織中的其他角色。
實驗室以外最重要的角色是具有很大權限的數據庫管理員 (DBA)，這個事實無需我們過分強調。可伸縮性問題最可能的根源就在於數據庫、數據訪問策略(例如，存儲過程、預處理語句或內聯 SQL)或數據訪問技術(例如，ADO、ODBC 等等)。DBA 能夠幫助識別和解決與數據庫相關的問題，例如建立索引成本過高、過度鎖定以及事務超時。理想情況是，您應有一位專門的稱職的 DBA 來作爲負載測試工作中關鍵點的全職資源。
我們還建議您讓開發團隊中的成員輪流負責測試實驗室，以便每名團隊成員都能參與到這項測試工作中。如果這樣做，您將取得極佳的交叉培訓的效果，並持續地向實驗室提供最新的理念。
定義測試策略
到目前爲止，您肯定參加過這樣的會議，客戶倚靠在寬大的會議桌上，問您：“這個系統能處理上千個用戶嗎?”傳統的負載測試方法要求您編寫腳本並執行測試，以試圖給出此問題的精確答案。對於這種測試，您需要定義“處理”的含義以及 1000 名典型用戶在站點活動時的情形。您需要定義測試用例以代表各種用戶活動：例如，購買股票或註冊新的帳戶。接下來，您必須估計用戶在這些測試用例上的分佈。對以下數據進行假設，即模擬真實用戶與應用程序交互時，需要多長的思考時間(或等待時間)。因此，負載測試期間活動的可從某個方面大致反映出同樣數量的真實用戶在站點活動時的情形。
這種方法有幾個不足之處。首先，其結果不會比您做的假設更好。顯然，不正確的假設將使結果出現偏差。
其次，估計真實用戶需要大量客戶端硬件。如果對每名虛擬用戶給定需要的處理能力和內存量，則典型的客戶端計算機可以處理大約 200 名虛擬用戶。因此，對 2000 名用戶併發處理級別的測試需要 10 臺客戶端計算機 — 這是一筆重大投資。測試使用 HTTPS 的站點將需要多得多的客戶端硬件。
最終，此方法難以向您的開發團隊提供以操作爲導向的信息。當某處出現故障時，常常難以再現該問題。
作爲備選方案，我們建議您圍繞以下這些關鍵問題設計測試用例：
? 系統瓶頸在哪裏?系統能同步處理多少個併發請求?
? 在響應時間變得不可接受之前，一臺機器能處理多少名不同步的超級用戶?
? 添加額外的硬件時，結果是線形增長的嗎?
? 有任何穩定性問題會妨礙站點運行於生產環境中嗎?
此方法將使用開發團隊(此開發團隊參與可能出現問題的領域)提供的附加信息。請關注這些領域。對於上一個示例，其瓶頸可能出在定單提交領域。從這裏您可以派生出更具體的問題，例如“提交流程可以同時處理多少個請求?”攻擊這些特定領域是最快且成本最小的方法，用來向開發團隊提供以操作爲導向的信息，以便他們能改進系統。在使用這種方法的同時，我們推薦您記住遵循以下建議。
關注負載測試正如我們已提到的那樣，首先要做的是構建導致潛在瓶頸和穩定性問題的腳本。這種“數據第一，假設第二”的方法使您能夠從應用程序收集原始數據，然後根據假設確定更高級別的結果。不用擔心爲識別低風險站點的腳本編寫問題。例如，爲站點的幫助領域或只讀文檔領域編寫腳本不大可能出現系統瓶頸。
同步請求使用同步請求攻擊瓶頸。此處的這個主意是模擬最壞的情況：即，站點上的用戶精確地在同一時間攻擊瓶頸。通過使用戶同步，您可以重複進行此測試。如果不同步結果，則難以再現故障情況。可以使用同步點做到這一點，同步點是大多數較健壯(成本也較高)的測試工具中提供的一項功能。同步點迫使每名虛擬用戶一直等到剩餘的用戶到達腳本中定義的點後，才能開始下一請求。它允許您精確並重復地確定站點的潛在瓶頸區域能處理的併發用戶數。例如，下限可以是 7 名併發同步用戶。
創建循環測試用例腳本使測試用例循環。在另一種方法中，每次測試用例迭代前後，站點應處於相同狀態。這允許您長時間地重複運行測試用例。
使用超級用戶最後，使用我們所稱的超級用戶。正如前面所提到的，超級用戶運行時思考時間設置爲零。請記住，思考時間假設是用於常規測試中，以使虛擬用戶模擬真實用戶。但是，如果將虛擬用戶思考時間減半，則服務器的實際負載將加倍。在另一種方法中，服務器真正關心的與負載有關的變量是每秒的請求數。虛擬用戶的數量及其思考時間結合起來生成該負載。
讓我們進行一些數學運算以使此概念更清晰。下面的公式計算訪問站點的真實用戶生成的負載(請求數/秒)：
例如，某個站點有 100 名併發用戶，假設下載時間爲 10 秒，思考時間爲 30 秒，則每秒將生成 2.5 頁。如果我們假設每頁 3 個請求，則在 Web 服務器上將轉化爲每秒 7.5 個請求。
以超級用戶運行測試時，觀察每秒請求數，並與剛剛計算的值比較。根據我們的經驗，真實用戶數與超級用戶數的比例通常約爲 15:1。對於同一個示例，這意味着 (100/15) 名超級用戶將生成與 100 名普通用戶相同的負載。再舉一個例子，假設在 10 名超級用戶之後響應時間變得不可接受。請注意轉換回真實用戶數的該點每秒請求數。現在您可以進行任何希望的思考時間假設，甚至可以更改它而無需重新運行測試。在幾天的測試之後，您將能根據直覺從超級用戶數轉換成真實用戶數。此方法允許您保持用戶數可控，減少所需的客戶端硬件數量，幷包含負載測試軟件的成本。
這些超級用戶測試用例對於多機測試很有用。要測試站點的可伸縮性，可添加第二臺 Web 服務器和一個負載平衡器，並重復超級用戶測試。理想情況下，在看見相同的相應次數之前，您將能加倍超級用戶數量。
要回答穩定性問題，可運行測試，以在延長的時間段內維持合理數量的併發且未同步超級用戶。我們在上一個項目中熬了很多個通宵，甚至 24 小時晝夜不停，但持續時間與應用程序有關。我們稱之爲“內置”測試。一旦您已採取步驟識別並潛在地解決了找到的瓶頸，則重複同步點測試，看下限是否有所增長。然後用所支持的新的併發用戶數重新運行“內置”測試。以努力提高此數字爲目標重複該循環，直到達到質量條。
但是有多少用戶呢?
儘管此方法向開發團隊提供了有價值的信息，但它使得您更難於回答會議室的問題。不過，您可以近似地估計答案。例如，假設站點的最壞情況瓶頸顯示，每臺計算機多於 20 名超級用戶的情況下，響應時間超過 10 秒。根據您從我們建議的公式計算的結果，近似地估計有 300 名真實用戶(20 名超級用戶 × 15 名真實用戶)。此時，您可以做出與常規用例中相同的假設。通常情況下，有百分之多少的用戶正在使用站點的此領域?假設預期 50% 的用戶正在使用此領域，而其他領域，例如文檔或數據庫讀取，用戶比例則沒有這麼大。這意味着具有一臺 Web 服務器的系統將處理大約 600 名用戶。
到目前爲止，我們已討論了在能明確地指向站點的一個瓶頸領域的情況下該如何做，但如果影響性能的領域不止一個時您又應如何做呢?答案是創建單獨查看各個領域的測試腳本。首先孤立地運行這些腳本，然後一起運行。再比較結果，看站點的一個領域對另一個領域的影響有多大。
瞭解度量標準
下一步是清楚地定義度量標準。度量標準的例子包括：每分鐘處理的定單數，或者執行對 ASP 頁面的請求所需要的毫秒數。度量標準允許您量化每次測試運行之間進行更改的結果。它們提供了與爲您的 Web 應用程序定義的標準之間的一種比較。
爲了確定需要跟蹤的度量標準，需要採取一系列步驟。您需要定義待回答的問題，爲每個問題定義質量條，然後確定將測試結果與質量條進行比較所必需的度量標準。
第一步很直接。例如，您可能想要了解簽出響應時間。請記住列出那些與測試策略相關的問題，而避免組織您無法測試的模糊問題。
下一步是爲每個問題定義質量條。讓我們以典型的定單提交流程爲例。我們可能決定站點在峯值負載期間每分鐘必須處理 10 份定單，一名用戶等到請求執行的時間不應超過 30 秒。爲了建立這樣一個標準，您可能會注意許多不同的源。首先諮詢業界人士，瞭解系統性能的可接受級別。將歷史數據帶到這些會議上將有助於討論，並常常可用來管理預期情況。如果在生產環境中已存在某個版本，則可以從當前站點活動和增加的通信量的短期投影收集數據，或通過查詢現有數據庫的活動趨勢來收集數據。
有了一份問題列表和每個問題的質量標準後，您現在就需要確定使用哪個度量標準。根據上一個例子，每分鐘定單數和給定測試中的定單數將是良好的高級度量標準，這些標準可作爲站點是否滿足質量條要求的指示器。當您想要在測試過程中更新這些度量標準時，應報告給管理層。
較低級的度量標準衡量性能並幫助您解決系統瓶頸和穩定性問題，或將這類瓶頸和問題減到最少。增加性能也許會對高級度量標準產生直接影響。例如，減少特定活動的事務時間可能導致每分鐘定單數的增加。
大多數測試工具允許您在個別頁上或一組頁上設置定時器，並提供運行測試用例的平均時間。兩種度量標準均允許您將高級度量標準用於一次又一次測試運行，但它們均不能幫助您深入瞭解到底是什麼需要改進。
對此 Windows 性能計數器很有用。例如，您可以監視 dllhost 進程的 Process:Private Bytes，以檢測服務器軟件包中的內存泄漏。有關各個Microsoft Internet 信息服務 (IIS) 計數器的適合且詳細的描述，可從The Art and Science of Web Server Tuning with Internet Information Services 5.0獲取，而圖 3描述了用於負載測試的主要計數器以及要注意的趨勢。
但是，性能計數器只在識別問題症狀時有用，對識別問題原因無用。如果您的系統在 20 名併發用戶時中斷，則 Active Server Pages:Requests Timed Out 計數器可以真正確認，至少一名用戶已超時，但要確定超時的原因卻如同大海撈針。這是因爲性能計數器數據主要提供操作系統和網絡級別的信息。要成功找到問題的原因，需要訪問應用層的數據。此任務的關鍵是，構建分佈式日誌記錄系統，以檢索並集中存儲來自應用程序中的錯誤和性能數據。這允許您立刻了解系統是否正在工作。如果系統沒有工作，則您就擁有了找到問題領域所必需的信息。
解釋度量標準
配置完所有這些度量標準之後，現在您就可以訪問大量數據。因此，您將如何以有效率的方式來理解數據?我們將針對解釋性能計數器數據討論三個選項：性能監視器、Perfcol 以及與負載測試工具集成的性能數據。
Windows 2000 中的性能監視器允許您以圖形的方式顯示各個計數器的進度。一個有用的功能是能夠在日誌文件中捕獲讀數，從而允許您在測試運行一完成就以可視的方式檢查整個測試運行。
沿着與性能監視器同一條線，Windows DNA Performance Kit Beta 包含一個稱爲 Perfcol 的工具。此工具的用途與性能監視器類似，不同之處在於該工具將取樣數據存儲在數據庫中，而不是寫入文件。
一些負載測試工具，例如 Microsoft Application Center Test (ACT) 和來自 Empirix 的 e-TEST 套件，均包含內置的性能計數器功能，它們能在測試的運行持續期間記錄度量值。然後計數器數據會寫入數據庫以供以後訪問。ACT 包含在 Visual Studio .NET 中，它集成了性能監視器計數器，允許所有數據均存儲在單個資源庫中。
不管負載測試工具是否集成某種形式的性能計數器監視，您也許均會發現仍需要諸如性能監視器之類的工具的支持，尤其是如果產生負載的服務器沒有適當的安全訪問權來監視應用程序服務器時，這種情況在環境包含防火牆時會頻繁發生。
無論選擇何種監視工具，關鍵在於存儲每次測試運行的度量標準以供將來評估。轉回到過去的數據對於理解系統如何響應所作的更改很關鍵。
對於日誌記錄系統生成的應用級數據，我們建議構建一個查看器，該查看器使您能夠立即訪問一個位置內的錯誤和性能信息。考慮到它所代替的操作是每次要求反饋時在命令行生成 SQL 查詢，因此這項工作還是值得的。
選擇適當的負載測試工具
要實施此項測試策略，您需要能選擇合適的負載測試工具。可用負載測試工具的完整評估已超出本文的討論範圍，但我們仍希望幫助您確定一些在選擇適當的工具時的選項和注意事項。
第一個選項是考慮諸如 Windows Application Stress Tool (WAST) 這樣的免費工具。另一方面，您還可以選用更爲靈活的工具，例如 ACT 或 Empirix 的 e-TEST 套件。圖 5顯示的是 e-Load 的界面，它是 e-TEST 套件的負載生成部分。
這些工具之間有一些明顯的功能差別。WAST 對於不太複雜的較小站點是不錯的工具。您可以輕鬆地測試站點上的兩三個關鍵頁面，並很好地瞭解響應率是多少。但是，僅僅一個能測試多頁面站點的隔離測試工具還是不夠的。而且，WAST 中沒有提供對於測試複雜站點必需的幾個重要功能(以及本文中一些建議的實現)。要使用 WAST 獲得複雜結果，需要您自定義應用程序，以便對其進行負載測試，這顯然是您所不希望的。
要執行我們針對複雜站點所建議的測試，諸如 ACT 或 e-TEST 套件之類的更健壯的測試工具將更有效。如果您在 .NET 中進行開發，那麼 ACT 將集成到整個開發週期中。但是，這需要 ACT 對象模型的編程技巧和知識，以生成強大的測試腳本。如果您決定使用諸如 e-TEST 之類的工具，則需要支付一筆許可費。
質量工具必須不僅僅能有效地測試站點，還能以有用的方式報告測試結果。ACT 和 e-TEST 均提供詳細的報告環境，允許您在需要的時候將結果繪製成圖像。ACT 結果界面顯示在圖 6 中。圖 7提供了公共特性的摘要，以及必須提供的每種工具類型的描述。
如果您確定更健壯的工具的確有必要，請不要低估啓動和運行必需耗費的時間。有些工具會宣稱只需幾個小時就能編寫開始測試所必需的腳本。如果您先前就有使用該工具或類似的負載測試工具的經驗，可能的確如此。但請做好耗費幾天甚至幾周進行準備工作的思想準備，所需的時間取決於站點的複雜程度。我們的第一個測試用例耗費了大約三週時間才啓動和運行。您可能會發現，儘管學習了一遍樣本教程，但仍有一些訣竅只能從實踐中學到，而且要經常致電支持熱線。耗費幾個小時學習工具，其效果可能遠勝於正規的訓練或聘請有經驗的顧問。而且，如果在開發階段的晚期開始測試工作，您將承擔不起浪費時間的損失，在這種情況下強烈建議使用以上兩項資源中的一項或全部。
瞭解歷史情況
您在一天之內甚至一週之內的測試數可能會變化。如果在調整 Web 服務器，則您可能決定運行一系列每小時一次的測試。如果您的目標在於測試應用程序的穩定性，則可能會整晚運行測試。不管是哪種方式，除非您保存一份文檔歷史記錄，否則要跟蹤從一個測試到下一個測試的變量和進度將會很難。有一點至關重要，即您能輕鬆地確定已進行了哪些測試、找到了什麼以及接下來應測試什麼。
至少應記錄運行的開始和結束時間、測試中的虛擬用戶量以及一份描述測試目標和更改內容的開始說明。以一份描述測試結果的結束說明完成運行。
小結
要成功部署複雜的 Web 應用程序，您必須首先採用超出系統測試範圍的“無驚訝”測試方法。負載測試由可伸縮性測試、性能測試和穩定性測試組成，它是發現體繫結構中主要內在問題的唯一方法。爲了達到此目的，您需要一個單獨的生產環境，環境中有類似的生產硬件、健壯的負載測試工具以及組織中若干人員的協作。
適當的度量標準可提供確定系統是否滿足質量條的方法。當然，對於可伸縮性實驗室團隊而言，最有價值的是分佈式日誌記錄系統捕獲到的錯誤和性能數據，因爲它能提供應用級的信息。
通過使用本文中討論的建議並確保記錄工作情況，可以很好地保證在計劃的日期內順利地進行部署。
