調和appstats Grand Total和apache bench的區別

我一直在使用appstats來檢查一些調用。我有一個簡單的視圖，可以調用memcache並返回結果。 Appstats告訴我總時間（總計）約爲15毫秒。但是，我在瀏覽器中觀察到的更像是242毫秒左右。實際上，我也使用apache bench來得到相同的結果。我嘗試了另一個網絡（使用ec2實例），看看我是否會看到不同的往返時間，並獲得了相同的結果。對服務器的ping需要大約13或14ms。調和appstats Grand Total和apache bench的區別

我絕對錯過了這裏的東西。大約有180-200毫秒的延遲，我無法解釋。基於w/app引擎和appstats的經驗，我希望有人能幫助我睜開眼睛看看我失去的東西。

一些環境細節如果感興趣... python 2.7;在測試中使用了webapp2和Flask;我的阿帕奇板凳測試都是單線程擊中100次。

感謝您的任何見解。

來源

2012-10-23 Jay

根據我的經驗，您總是會看到appstats和總時間之間的差異。你可以在日誌中看到這個。列出總延遲時間。 Appstats爲您提供了處理請求所需的時間，但日誌列表總共I/O時間。從我所能做的事情來看，增加的時間可以歸結爲負載平衡以及應用程序引擎內部排隊請求的方式，並評估是否需要縮放請求。另外，如果您發送100個請求的突發事件，則實際上可能會使差異更明顯，因爲根據您的應用程序設置，最有可能在新實例啓動之前在最少的實例上提供這些請求。

如果你希望你的應用程序運行良好，一個好的經驗法則是appstats在100ms以下，剩下的就是你要燒多少錢。

是否有興趣在官網上，但是這就是它看起來像我3年後與App Engine

來源

2012-10-24 06:07:20

我認爲你是對的賈斯汀工作。讓我在這裏的東西是延遲的_amount_。爲了進一步測試，我部署了一個裸露的骨骼「hello world」類應用程序。 App Engine的服務時間爲63毫秒左右。同樣的應用程序（本質上）部署到heroku的服務時間爲18毫秒。當然，heroku應用程序幾乎就像坐在那裏的一個ec2實例 - 沒有自動縮放。現在在不同的時間測試，應用程序引擎實例在130ms內響應。這是零rpc電話。所以延遲的變化取決於發生了什麼。我希望它少一點，但嘿。 – Jay

是的，在appengine Status頁面上，您可以看到可變延遲，並且我也看到了幾天請求需要花費兩倍的時間才能完成周轉。這就是應用程序設置滑塊用於等待延遲的地方。 –

調和appstats Grand Total和apache bench的區別

回答

相關問題