重新加載mod_wsgi守護進程時的停機時間？

Question

我使用mod_wsgi在Apache上運行Django應用程序。升級過程中是否有停機時間？

Mod_wsgi在守護進程模式下運行，因此我可以通過觸摸.wsgi腳本文件來重新加載我的代碼，如「ReloadingSourceCode」文檔中所述：http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode。據推測，該重新加載需要一些非零時間。如果在重新加載期間發出請求，會發生什麼情況？ Apache將排隊請求，然後在wsgi守護進程準備好後完成它？

文檔包括以下語句：

所以，如果你在守護模式下使用Django和需要改變你的「settings.py」文件，一旦你已經完成了必要的改變，也碰包含WSGI應用程序入口點的腳本文件。完成之後，在下一個請求過程中將重新啓動並重新加載Django應用程序。

對我而言，這表明Apache會優雅地處理每個請求，但我想我會要求確定。我的應用並不重要（有點宕機不會造成災難性的），所以問題主要是學術問題。

謝謝。

Answer 1

在守護模式沒有平穩重啓的概念時WSGI腳本文件被觸摸到強制下載。也就是說，與Apache本身不同，它將啓動新的Apache服務器子進程，同時等待舊進程完成當前請求，對於mod_wsgi守護進程進程，現有進程必須在新進程啓動之前退出。

這樣做的後果是mod_wsgi的不能無限期地等待當前的請求完成。如果確實如此，那麼存在這樣的風險，即如果所有守護進程都被捆綁在等待當前請求完成的時候，那麼客戶端將會看到被處理的明顯延遲。

然而，在規模的另一端，守護進程不能立即被殺死，因爲這會導致當前請求被中斷。

因此，一箇中間接地存在。守護進程將在退出之前等待請求完成，但是如果它們在關閉期間內沒有完成，則守護進程將被強制退出，並且活動請求將被中斷。

此關閉超時的週期默認爲5秒。可以使用WSGIDaemonProcess指令的shutdown-timeout選項覆蓋它，但應該考慮改變它的效果。

因此，就此特定問題而言，如果在觸摸WSGI腳本文件後第一個請求進入時，長時間運行的請求仍處於活動狀態，則存在長時間請求被激活的風險。

您可能會看到另一個值得注意的事情是，即使沒有長時間運行的請求，並及時處理關機，那麼它仍然需要在新的進程中又加載了WSGI應用。這需要的時間將被視爲延遲處理請求。這個延遲有多大將取決於框架和您的應用程序。就我所知，啓動時間最差的是TurboGears。 Django稍微好一點，最好的就是快速啓動時間，像Flask這樣的輕量級微框架。

請注意，發生這些關機和啓動延遲時出現的任何新請求都不應丟失。這是因爲HTTP偵聽器套接字具有一定的深度，並且連接排隊等待被接受。如果到達的請求數量很大，並且該隊列填滿，那麼您將開始在瀏覽器中看到拒絕連接錯誤。

Answer 2

不，不會有停機時間。使用舊代碼的請求將完成，新請求將使用新代碼。

會有服務器作爲新的代碼加載更小一點的負載，但除非你的應用是巨大的，你的服務器已經接近過載，這將是不明顯的。

這就好比apachectl graceful命令爲Apache作爲一個整體，它告訴它來啓動新的配置，無需停機。