2011-11-23 43 views
1

我在玩GAE,做了一個非常小巧的應用程序,它可以獲取微小的請求並以恆定的速率輸出微小的響應(來自使用cURL和循環的程序)。如何確定性能下降的原因?

它不處理用戶界面,它不打算從瀏覽器中調用,它只是接收POST請求,做一些處理並將光數據作爲ASCII文本輸出。

我已經設法優化我的應用程序,以便平均延遲通常爲20-30毫秒,並且目前爲止效果很好,單個實例可能很容易管理每秒十幾個查詢,因爲非常低延遲。

但是,今天早上,大約40分鐘,性能下降出現大幅上升,應用程序開始需要20,000到30,000毫秒來處理請求,請參閱:http://i.imgur.com/OWQdd.png。 GAE應用程序代碼在此期間沒有更改,也沒有發出請求的程序。

我怎麼知道這是什麼原因以及未來會再發生? 我檢查了日誌,沒有發現任何問題,因此無法聯繫Google。

我的應用程序對等待時間非常敏感,所有請求都應該儘可能快地處理,當然也不會超過1秒。

我在我的應用程序的管理面板中設置10毫秒的最低掛起延遲時間,但是有沒有辦法減少請求的最大超時時間?我認爲默認情況下是60秒。


編輯:這裏是other charts在這裏我們可以看到什麼affeted是「API調用CPU」和「活動情況」,但我不知道怎麼樣,告訴我出了什麼問題?


EDIT2:下面是在有問題的時期,發生了一些請求日誌條目:

69.165.137.199 - - [23/Nov/2011:06:56:11 -0800] "POST/HTTP/1.1" 200 287 - - "app.appspot.com" ms=36378 cpu_ms=258 api_cpu_ms=98 cpm_usd=0.007259 instance=00c61b117cd98a4e8f9d6c0215d5e14c3336 
69.165.137.199 - - [23/Nov/2011:06:55:32 -0800] "POST/HTTP/1.1" 200 287 - - "app.appspot.com" ms=34584 cpu_ms=125 api_cpu_ms=98 cpm_usd=0.003555 instance=00c61b117cd98a4e8f9d6c0215d5e14c3336 
+0

您是否可以爲您的問題中緩慢的請求添加一些日誌條目? –

+0

嗨,不幸的是,在動盪的時間段內沒有日誌條目,沒有信息或錯誤記錄發生...... – ibiza

+0

真的嗎?您確定您將日誌查看器設置爲「所有請求」,而不是「最低嚴重性:錯誤」(這是默認設置)?你能從前後立即粘貼兩個日誌條目嗎? –

回答

2

這裏有一些事情要嘗試:

  • 嘗試以不同的名稱再次部署它(使新的默認值),並查看性能是否回來。如果確實如此,那麼可能會導致它在運行時放慢速度。
  • 檢查您的數據存儲區有多大。在使用大型數據集進行測試時,您可能會遇到一些查詢速度慢的問題。
  • 下載將Appstats here is a tutorial,並按照本指南性能分析
  • 如果您使用的是你從它返回的數據,而不是如果您使用的任務隊列做其他數據存儲查詢
  • memcache的檢查,確保人們沒有不會卡住。您可以從管理頁面手動運行它們。
+0

感謝您的回覆,我會嘗試使用appstats。我的應用程序在運行時不應該放慢速度,因爲在大約40分鐘的掙扎後性能回來(現在它再次運行得非常好)。我的數據存儲很小,所以它不應該關聯,我正在有效地使用memcache(測試)從memcache/datastore檢索數據。沒有使用任務隊列。再次感謝! – ibiza

1

您是否從日誌中檢查了花費時間?在CPU中,掛起狀態還是在API中?根據我的經驗,數據存儲有時會這樣做,沒有明顯的原因,所以您的應用沒有任何問題。嘗試高複製數據存儲如果穩定延遲很重要,但它的最小延遲稍高。

+0

嗨,謝謝,看看我的編輯,以找到可能有用的其他信息...但我不知道在哪裏可以獲得關於歷史數據存儲操作或任何其他信息的更多詳細信息,對嗎?在'日誌'選項卡中,我只能看到消息(錯誤,信息,調試),沒有任何意義或連接到發生的情況。 – ibiza

+0

哦,我已經在使用HR數據存儲 – ibiza

+0

您可以在管理控制檯中至少單擊最近的日誌條目,並查看類似如下內容:ms = 57 cpu_ms = 47 api_cpu_ms = 8 cpm_usd = 0.001365。根據你的圖表,我會責怪數據存儲。 –