我已經使用jMeter來測試我的appengine應用程序性能。App Engine應用程序性能測試
我已經創建了一個線程組
- 500的用戶,
- 斜坡上升期間:0秒
- 和環1
和運行測試。
它在應用程序引擎中創建了4個實例。但有趣的是,> 450個請求由單個實例處理。
我已經用這個實例再次運行測試,仍然大部分的請求(> 90%)都去了相同的實例。
- 實例類型:F1級
- 交費實例:(自動)
- 閔噴丁延遲:(自動)
我得到較大的延遲。
這裏怎麼回事? 從1個IP生成負載,是否有任何問題?
我已經使用jMeter來測試我的appengine應用程序性能。App Engine應用程序性能測試
我已經創建了一個線程組
和運行測試。
它在應用程序引擎中創建了4個實例。但有趣的是,> 450個請求由單個實例處理。
我已經用這個實例再次運行測試,仍然大部分的請求(> 90%)都去了相同的實例。
我得到較大的延遲。
這裏怎麼回事? 從1個IP生成負載,是否有任何問題?
這完全是App Engine的問題...
當你說「我得到更高的延遲」你到底是什麼?你認爲它太慢了嗎?
如果延遲是一個問題,那麼您可以減少應用程序設置中的最大待定延遲。如果你嘗試這個,我想你會看到你的請求在更多的實例中傳播。
我的猜測很簡單,就是2-3個閒置的實例已經預料到負載會增加,但實際上並不需要進行測試。
你的問題是你沒有使用現實的斜坡價值。與大多數自動擴展解決方案一樣,AppEngine需要合理的時間來啓動新硬件。在此過程中正在創建新實例時如果流量出現大量突然增加,延遲可能會增加。
選擇一個斜坡上升值,它代表您實際預計在生產中看到的尖峯/浪涌類型,然後運行測試。使用這個測試的值來決定你想要「永遠在線」多少個appEngine實例,這個值越高,浪涌的影響就越小,但顯然你的成本越高。
我指定了,我再次運行了這個實例的測試(4個實例),仍然大部分請求(> 90%)都是相同的實例。並給我提供錯誤和高延遲值 – Dipin 2012-03-16 02:13:55
您可能希望從另一個方向着手:如果您計算出部署此應用程序後期望獲得的最高峯值,那麼您可以配置測試以表示該測試。這基本上是一個給定的(從我的經驗),appEngine不適用於大容量,非常流行的應用程序,它不是設計(完全)用於積極的綜合負載測試。注意。谷歌正在使用某種狀態檢查來決定如何平衡負載,這是基於間隔的_可能性,因此您需要緩慢提升的原因... – 2012-03-16 10:00:51
此答案沒有正確的解釋。即使鏈接也有權限問題。 – Jahan 2016-09-08 07:09:25