2012-03-14 144 views
8

我已經使用jMeter來測試我的appengine應用程序性能。App Engine應用程序性能測試

我已經創建了一個線程組

  • 500的用戶,
  • 斜坡上升期間:0秒
  • 和環1

和運行測試。

它在應用程序引擎中創建了4個實例。但有趣的是,> 450個請求由單個實例處理。

我已經用這個實例再次運行測試,仍然大部分的請求(> 90%)都去了相同的實例

  • 實例類型:F1級
  • 交費實例:(自動)
  • 閔噴丁延遲:(自動)

我得到較大的延遲。
這裏怎麼回事? 從1個IP生成負載,是否有任何問題?

回答

0

當你說「我得到更高的延遲」你到底是什麼?你認爲它太慢了嗎?

如果延遲是一個問題,那麼您可以減少應用程序設置中的最大待定延遲。如果你嘗試這個,我想你會看到你的請求在更多的實例中傳播。

我的猜測很簡單,就是2-3個閒置的實例已經預料到負載會增加,但實際上並不需要進行測試。

+0

爲特定的測試,我得到的大約平均延遲。 10秒。在正常情況下(不使用Jmeter壓力測試),平均值大約爲50毫秒。如果跨越多個實例的請求,我可能會得到更好的結果。我會嘗試你的解決方案。並讓你知道。謝謝。 – Dipin 2012-03-14 18:01:53

+0

我仍然有疑慮,爲什麼第二次測試也採取了同樣的實例運行,並給了我更高的延遲。其中只有少數人使用其他人。 – Dipin 2012-03-14 18:04:20

+0

實例數量增加,分佈略有變化,仍然有很高的延遲值。 – Dipin 2012-03-16 02:15:29

3

你的問題是你沒有使用現實的斜坡價值。與大多數自動擴展解決方案一樣,AppEngine需要合理的時間來啓動新硬件。在此過程中正在創建新實例時如果流量出現大量突然增加,延遲可能會增加。

選擇一個斜坡上升值,它代表您實際預計在生產中看到的尖峯/浪涌類型,然後運行測試。使用這個測試的值來決定你想要「永遠在線」多少個appEngine實例,這個值越高,浪涌的影響就越小,但顯然你的成本越高。

+0

我指定了,我再次運行了這個實例的測試(4個實例),仍然大部分請求(> 90%)都是相同的實例。並給我提供錯誤和高延遲值 – Dipin 2012-03-16 02:13:55

+1

您可能希望從另一個方向着手:如果您計算出部署此應用程序後期望獲得的最高峯值,那麼您可以配置測試以表示該測試。這基本上是一個給定的(從我的經驗),appEngine不適用於大容量,非常流行的應用程序,它不是設計(完全)用於積極的綜合負載測試。注意。谷歌正在使用某種狀態檢查來決定如何平衡負載,這是基於間隔的_可能性,因此您需要緩慢提升的原因... – 2012-03-16 10:00:51