我在Azure Web服務上使用JMeter運行負載測試。 我使用4個實例在S2上擴展我的服務,並運行帶有500個線程的JMeter 4實例。Azure上的負載測試
它開始非常好,但過了一段時間後調用開始失敗,並給予超時錯誤(HTTP狀態:500)。
我已經檢查了azure上的HTTP請求隊列,發現它在第二個實例中非常高,兩個實例非常低低。
請幫我成功我的負載測試。
我在Azure Web服務上使用JMeter運行負載測試。 我使用4個實例在S2上擴展我的服務,並運行帶有500個線程的JMeter 4實例。Azure上的負載測試
它開始非常好,但過了一段時間後調用開始失敗,並給予超時錯誤(HTTP狀態:500)。
我已經檢查了azure上的HTTP請求隊列,發現它在第二個實例中非常高,兩個實例非常低低。
請幫我成功我的負載測試。
我假設您正在使用Azure應用服務。如果您檢查應用程序的設置,您會注意到ARR的實例相關性將默認啓用。一個簡單的解釋:
ARR聰明地跟蹤連接用戶,給他們一個特殊的cookie(稱爲親和cookie),它允許它在隨後的請求中知道他們正在與哪個服務器實例通話。這樣,我們可以確定,一旦客戶端與特定服務器實例建立會話,只要他的會話處於活動狀態,它就會繼續與同一服務器通話。
這是會話敏感的應用的一個重要特徵,但如果不是你的話,那麼你可以放心地將其禁用,以提高您的實例之間的負載均衡,避免像你所描述的情況下一個。
Disabling ARR’s Instance Affinity in Windows Azure Web Sites
這可能是由於在JVM的網絡名稱解析或OS水平,使所有的請求都命中率只有一臺服務器的緩存。如果是這種情況 - 將DNS Cache Manager添加到您的測試計劃,它應該可以解決您的問題。
請參閱The DNS Cache Manager: The Right Way To Test Load Balanced Apps文章以獲得更詳細的說明和配置說明。