ASP.NET Web Services + IIS性能診斷

Question

需要在大負載下找到服務器應用程序中的性能瓶頸。應用程序由單個服務實例（.asmx）和一些通過http請求的文件組成。我計劃解決這個問題的方法是：1）當服務器啓動失敗時得到異常情況2）分析當時的性能計數器和日誌以扣除造成這種情況的呼叫類型。

爲了開始實現這個，我實現了一個特殊的客戶端，它發出兩種類型的請求，並使其無限期地重複相應的循環，希望在某些時候我會在WebMethod/GET url請求期間收到錯誤（NB - 標準的已有解決方案像JMeter和WAPT不能用於複雜的服務使用場景）。到目前爲止，我正在觀察的是服務調用中的響應時間增加以及文件加載期間的某些網絡超時異常（使用根據 - this thread引發的OperationCanceledException被認爲超時的HttpClient）。順便說一句，這很奇怪，因爲文件的大小很小，服務方法每個請求返回5-10mb的數據。認爲「更大」的請求更可能首先失敗。
Perfmon顯示CPU負載增加，絕對沒有內存尖峯/泄漏。請求執行時間計數器是非常隨機的，看起來不相關，隊列長度始終爲0.
也就是說，看起來像IIS處理我的臨時DDoS並同時使測試方法無效（響應時間增加意味着內存中的更多活動請求測試客戶端會導致內存溢出，並且我在收到數據後沒有對它做任何處理就已經刷新了數據）。
更多細節：服務器機器是4x3Ghz核心，4 Gb RAM。我生成每秒50-100個請求的負載，導致10-20 Mb/sec帶寬（測試客戶端位於服務器數據中心內的虛擬機上，4 Gbps NIC）。 30分鐘的測試會話是服務器和客戶端之間10-30Gb的純數據傳輸。
我怎樣才能讓Web服務/ IIS停止運行？

Answer 1

首先，我不會寫我自己的負載測試工具;有很多可用的。我用JMeter（開源）。您可以使用JMeter（以及其他類似的工具）發送POST和GET parameters，cookie和其他HTTP頭文件 - 儘管承認，這對於複雜的情況確實具有挑戰性。

接下來，確保你的問題確實是服務器，而不是其他基礎設施 - 網絡，路由器，防火牆等，都有最大的能力，並且可能是問題的根本原因。他們大多數都有日誌和報告工具。例如，我見過測試在達到防火牆的最大容量時報告吞吐量問題;服務器甚至沒有接近突破點。發生這種情況是因爲我們在測試用例中包含了一個相當大的二進制文件，這通常是從CDN提供的。

接下來，就整體而言，提供靜態HTTP請求不太可能出現問題 - IIS確實是這樣的，確實是good。對於你提到的那種硬件，我希望能夠每秒處理數千個請求。對於靜態文件。

在大多數情況下，導致問題的是動態頁面 - 您的.asmx。所以，我會忽略負載測試中的所有靜態文件，並專注於.asmx。在你提到的那種硬件上，如果asmxes工作正常，你可能需要每秒生成數百個請求。

假設您的Web服務器調整正確並且asmx腳本具有合理的性能，我希望至少需要測試系統的兩倍（CPU和內存）容量，因爲您的服務器必須帶上它的突破點（這是基於我對JMeter的經驗，它不像我的Web應用程序那樣高效，但可以輕鬆部署多個測試客戶端）。所以在你的情況下，我會尋找2臺符合你的服務器規格的機器。使用JMeter（以及我所使用的幾乎所有其他負載測試工具），您可以很容易地使用多臺機器作爲負載測試客戶端;我還使用JMeter使用了基於雲的負載生成。

我不完全確定爲什麼這個經驗法則是真實的 - 但我已經在多個項目中觀察到它。