2011-02-28 59 views
3

Azure,亞馬遜和其他基於實例的雲提供商可以用來執行網站負載測試(通過旋轉運行程序的衆多實例,將請求發送到一組URL),我想知道如果我能用Google App Engine來做到這一點。使用谷歌App Engine進行網站負載測試

到目前爲止,似乎並非如此。我現在唯一可以考慮的實現是設置每個執行頻率最高的cron作業的最大數量,每個任務請求一堆URL,同時彈出task queue的進一步任務。

根據我的計算,這只是夠火了最大25個併發請求(作爲一個應用程序可以在每個maximum 20 cron tasks比每分鐘一次,默認隊列爲5 task invocations per second吞吐率執行沒有更加頻繁。

任何想法,如果有一種方法,我可以在一個自動化的方式獲取URL的更多的併發請求

回答

4

taskqueue API允許每秒100任務調用每個隊列具有以下最大活動隊列配額:

免: 10活性隊列(不包括默認隊列)

帳單: 100活性隊列(不包括默認隊列)

隨着每個任務的單個網址抓取,乘以[最大數量活動隊列] * [每秒任務調用] * [60秒]的最大數量可以達到標稱的這些要求的URLFetch率:

免費: 11 * 100 * 60 = 的URLFetch調用/分鐘

帳單: 101 * 100 * 60 = 的URLFetch調用/分鐘

這些比率是由number of allowed UrlFetch per minute quota限於:

免費: 3,000個通話/分鐘

結算: 32000呼叫/分鐘

正如你所看到的,TASKQUEUE +的URLFetch的API可以有效地使用以滿足您的負載測試的需要。

+0

這並不意味着這是一個好主意--App Engine確實不是一個負載測試工具,而是構建爲面向用戶的web應用程序。 – 2011-03-01 02:20:04

+1

@尼克我不明白爲什麼不。你介意告訴我們這種方法的缺點嗎?謝謝。 – systempuntoout 2011-03-01 07:50:38

+0

輝煌,沒有意識到進一步的任務隊列可以建立的可能性。 – 2011-03-01 16:38:07

2

針對公共URL進行負載測試可能不如將框直接連接到與目標服務器相同的交換機那樣準確。有太多無法控制的網絡效應。

根據您的具體情況,我建議借用幾個桌面盒用於目的和使用它們。任何一半體面的機器應該能夠每分鐘產生2-3萬個電話。

這就是說,它真的取決於你想達到的目標規模。