在Google App Engine中啓動Django實例

在想了解如何製作一個快速且可擴展的Web應用程序之後，我幾乎決定結合使用Google App Engine，Python + Django和應用程序引擎補丁。但是，我在app-engine-patch FAQ中發現了一條評論，這讓我覺得這個組合可能不像我想象的那麼成熟：根據FAQ，它可能需要幾秒鐘才能啓動一個Django實例。如果從請求到請求有一定的持久性，這可能不成問題，但似乎沒有持續的流量時，Django實例將在幾秒鐘內關閉。如果系統每隔一秒鐘都不會被調用，則任何傳入的請求都需要秒（！）才能被授予。這是無法接受的。作爲一個快速修復（我知道是醜陋的），我正在考慮讓外部機器每秒鐘向該框架發出虛擬請求，以保持活躍。在Google App Engine中啓動Django實例

你同意這個嗎？你有其他方法嗎？

另一個疑問是，如果有足夠的流量從一個n服務器跳到n + 1會發生什麼情況，請求將需要幾秒鐘才能被授予，因爲必須啓動新的Django實例？或Google的基礎架構不能以這種方式工作？我承認我對此無知。問題。

幫助！

來源

2009-09-26 cpicada

我尊重你正在嘗試做的事情，但這聽起來有點像對我來說過於成熟的優化。你正在討論的py + django補丁是Google推薦的，直到他們升級到「真正的」django，所以我無法想象它是如此糟糕。測試你所談論的內容的表現也並不難，所以我建議你在做出最終決定之前先這樣做，然後運行一些指標。這樣，你就會有一些數學對其進行備份，當別人開始抱怨;）

來源

2009-09-26 19:38:33 slf

「，直到他們升級到「真正的」Django「？目前的解決方案並非「虛幻」Django--由於Django的侷限性，補丁只是必需的。 – 2009-09-26 21:01:53

是的，啓動時間長是使用框架與大量的代碼的警告。除了使用輕量級框架（比如內置的webapp框架）之外，目前還沒有辦法繞過它們。

輪詢不建議您的應用程序：它會用完的配額，而實際上並不保證真正用戶請求打你的輪詢請求做了同樣的情況，因爲應用程序在多個實例上運行。

幸運的是，有一個簡單的解決方案：獲得流行！您的應用越流行，需要重新啓動的實例越少，影響的用戶比例越小。

來源

2009-09-26 21:06:48

謝謝尼克。我同意你的意見。獲得流行是真正的解決方案。我提出的修復方案是爲了避免出現22級的情況，因爲這個頁面很糟糕，所以你不會受歡迎，而且它很糟糕，因爲它不太受歡迎！ – cpicada 2009-09-26 22:14:32

是的，公正的警察 - 這是一個合理的關注。雖然在短期內沒有太多的工作要做。然而，我對Unladen Swallow寄予厚望。 ;） – 2009-09-27 19:33:28

漸漸流行並不簡單。 – dfrankow 2009-12-31 14:41:04

而且，在我看來，（但尼克可以在這裏糾正我，如果我錯了），如果你使用內置在Django（0.97或1.0）裝載不成問題的。從邏輯上講，我會說他們將內置的libs保存在每個人的內存中，或者在實例之間共享緩存的代碼。但我不確定。

來源

2009-09-27 11:53:19

更新：現在我再次包括我自己的Django，因爲內置的1.0給了我奇怪的超時問題。 – 2010-01-01 23:45:24

請參閱Takashi Matsuo's comparisons。基本上，對於最簡單的應用程序引擎補丁程序，幾乎沒有任何功能，他聲稱約爲1秒，而對於webapp + Django模板約爲350毫秒。

感覺就像大於1s爲我們的應用程序較長，但隆只是嘗試，他能想到的最簡單的很程序。

來源

2009-12-31 14:40:06 dfrankow

他們還提到在使用Django的壓縮版本將有助於加載時間的常見問題，但我猜它可能仍然是漫長的。至於你原來的問題，我與其他人查詢您的應用程序可能不是一個好主意，因爲它可能不會解決你的問題，因爲谷歌可以在許多臺機器分佈您的請求，同意等，等

來源

2010-01-11 02:54:04 Bialecki

在Google App Engine中啓動Django實例

回答

相關問題