GAE啓動動態實例來爲請求提供服務，而不是使用閒置的駐留實例

我檢查了一堆關於像這樣的相同主題的其他帖子：「Resident instance does not seem to work」但我找不到工作的答案對於我的問題GAE啓動動態實例來爲請求提供服務，而不是使用閒置的駐留實例

我有4 F2居民，每當有人去我的應用程序，而不是使用駐留實例，一個新的動態實例被掛載回答請求。所以試圖使用我的應用程序的人將等待20秒。然後所有新的請求都會到達新的動態實例。我的常駐實例的響應時間低於我的最低等待時間（5秒）。我的應用程序自昨天開始生產，如果沒有人使用它5分鐘，那麼下一個將連接的人將需要等待20秒！根據我讀過的內容，有人會說如果我將最小空閒實例設置爲4（爲了讓我的駐留實例）GAE將嘗試一直有4個空閒實例，所以我們將啓動新的實例;但之後我總是需要等待35秒才能開始第一次連接。使用應用程序2分鐘後，一切都很好。一位在Google工作的人告訴我，駐留實例的管理存在一個錯誤，並且我必須有3個駐留實例才能爲我的用戶快速回答問題。我敢肯定，我沒有理解的東西。任何人都可以幫我讓我的用戶有一個公平的響應時間，當他們連接到我的應用程序，並沒有人連接5分鐘，請？

非常感謝您

來源

2013-05-02 Mike

下面是相關的問題（有可能是其他人）：

http://code.google.com/p/googleappengine/issues/detail?id=7706

好像有人有成功有5，但是從你的研究和其他意見我已經閱讀它可能只是更多的機會更好。

來源

2013-05-02 14:56:35

謝謝爲了您的回答，我可以看到其他人也在爲這類問題而苦苦掙扎。我將用5個實例進行一些測試，並在這裏分享結果。歡迎任何其他提示！ – Mike 2013-05-02 15:21:11

期待聽到您的結果。此外請確保明星問題:) – 2013-05-02 15:23:13

我已經做了以下測試，這可能對GAE上的低流量應用有用： – Mike 2013-05-02 16:41:28

查看谷歌組的GAE郵件列表，你會看到這個問題一遍又一遍地出現。

簡短的回答是，GAE是爲高負載設計的。雖然我沒有真正看到「尖峯」的正式定義，但駐留實例存在可以處理工作負載的峯值。如果GAE的神祕負載均衡算法不能確定您的流量爲高峯，您將獲得一個新的動態實例。

如果您在應用程序中發出數百或數千請求，則其中一些請求會在等待動態實例啓動時被引導至駐留實例。

沒有太多的事情可以做，但加入了長長的投訴人羣。有針對此提出申請至少兩個問題：

https://code.google.com/p/googleappengine/issues/detail?id=7865&q=scheduler&colspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Log

https://code.google.com/p/googleappengine/issues/detail?id=7706&q=scheduler&colspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Log

或者你可以重寫你的應用程序，讓你沒有一個20多歲的啓動時間。有幾件事你可以做，比如推遲大部分的加載，但是在Java中這很痛苦。

另一方面，python和Go運行時似乎啓動速度要快得多。

來源

2013-05-02 15:13:44 dragonx

我伸手，似乎現在是確定一個切實可行的解決方案：我已經做了以下的測試至極可能是有用的GAE上低流量的應用：

測試1 - > 5xF2 iddle至極5秒待定延遲的結果：即時通訊仍然得到一個預熱馬上作爲用戶 -
試驗2 - > 8xF2 iddle與5秒待處理延遲時間：同上
試驗3 - > 8xF1居民5秒待處理延遲時間：同上
測試4 - > *** * 1xF4駐留15秒掛起延遲****：方式更好。應答（50到100個第一請求）的實例是居民，然後打開一個動態實例。並在2分鐘後關閉而不使用我的應用程序。幾乎就像我夢想GAE會工作一樣 - 因此在過去的4天裏，它對1xF4居民和15秒等待時間的延遲效果很好。 -

如果出現新的問題，即時通訊思想這天，最好的方式，以避免對用戶冷的創業是來ping我的應用程序，每30秒，我會努力有一個更快的冷啓動時間

來源

2013-05-05 12:06:48 Mike

GAE啓動動態實例來爲請求提供服務，而不是使用閒置的駐留實例

回答

相關問題