在GAE中實現一致的響應時間？

Question

對我的應用程序在運行時負載測試我看到了非常一致的響應時間。一旦GAE的負載水平不變，平均響應時間就會越來越小。 但我希望在每秒接收少得多的請求的其他應用程序上具有相同的一致性。在那些我從來不需要支持超過〜3個請求/秒。

Reading the docs讓我覺得提高最低空閒實例的數量應該導致更一致的響應時間。但即使如此，客戶仍然會看到更高的響應時間，每次GAE的調度程序認爲需要更多實例。我正在尋找一個設置，用戶不會看到最初的慢速請求。

當我提高最低空閒實例1的數量，我想GAE只使用一個居民實例。隨着負載的增加，它應該啓動並預熱新的（動態）實例。 Only once they are warmed up，GAE應該向他們發送請求。 但從響應時間來看，它似乎就像客戶端請求在動態實例中到達時一樣。因此，這些請求需要很長時間（最多30秒）。

• 可以，如果我熱身的代碼是不完整出現這種情況？
• 可以在動態情況下，第一個電話是如此緩慢，因爲它們涉及尚未回暖尚未代碼路徑？

我在加載測試或足夠的人使用該應用程序時沒有遇到此問題。但是，當沒有人使用該應用時，我的測試環境幾乎無法被客戶使用。在早上。

謝謝！

Answer 1

一些通用的想法：

• 30秒啓動時刻的情況下顯得非常多。我們做了很多初始化（包括數據庫命中），並且我們有大約5秒的開銷。
• 預熱，請求將無法得到保證。如果所有實例都很忙，並且調度程序認爲如果啓動新實例而不是在繁忙的實例上排隊時，該請求將得到更快的響應，則它將這樣做沒有浪費了預熱請求的時間
• 不要以爲這是一個寒冷的代碼路徑的問題（雖然我不知道Java的詳細熱點），它可能是（MEM-）高速緩存，其需要填補第一
• 我不知道你是什麼意思是「不完整的熱身代碼」;只需檢查您的日誌中是否存在/ _ah/warmup的請求 - 如果有任何請求，則啓用並運行預熱請求。
• 增加超過1個實例標記的空閒實例的數量在這裏可能無濟於事。

可悲的是，沒有任何通用的技巧，以避免這一點，但你可以嘗試

• 延遲初始化代碼（僅做實例啓動開銷的絕對必需的最低限度）
• 啓動一個後端，使（緩存）緩存保持熱度

如果您不介意成本（並且不需要您的低容量應用程序自動縮放），則甚至可以讓所有請求始終由始終服務 - 在後臺