Django開發服務器重新加載需要太長時間

Question

這是我的問題，因為我升級到OSX Lion：每當我在Django項目中更改文件時runserver重新加載，它需要很長時間才能再次開始服務。

即使在新創建的Django 1.4項目中也會發生這種情況。 雖然在Snow Leopard上沒有這個問題。

我使用了cProfile，這是它花費大部分時間的地方：

Ordered by: cumulative time

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    1    0.001    0.001   48.068   48.068 manage.py:2(<module>)
    1    0.000    0.000   48.033   48.033 __init__.py:431(execute_manager)
    1    0.000    0.000   48.032   48.032 __init__.py:340(execute)
    1    0.000    0.000   47.908   47.908 base.py:182(run_from_argv)
    1    0.000    0.000   47.907   47.907 base.py:193(execute)
    1    0.000    0.000   47.814   47.814 runserver.py:39(handle)
    1    0.000    0.000   47.814   47.814 runserver.py:69(run)
    1    0.001    0.001   47.814   47.814 autoreload.py:129(main)
    1    0.000    0.000   47.813   47.813 autoreload.py:107(python_reloader)
    1    0.000    0.000   47.813   47.813 autoreload.py:96(restart_with_reloader)
    1    0.000    0.000   47.813   47.813 os.py:565(spawnve)
    1    0.000    0.000   47.813   47.813 os.py:529(_spawnvef)
    1   47.812   47.812   47.812   47.812 {posix.waitpid}
    ...

但我不明白為什么？

Answer 1

（對於仍在谷歌搜索答案的人）

我使用Vagrant（在Windows主機上）有類似的問題。 解決方案對我來說是移動virtualenv文件夾遠離同步/vagrant 。 同步文件夾的默認設置使用VirtualBox提供程序，這就是問題所在。 我們可以通過Vagrant官方文檔中的另一種同步方法來了解這一點：

在某些情況下，默認的共享文件夾實現（例如VirtualBox共享文件夾）具有高性能損失。 如果您發現同步文件夾的性能不佳，NFS可以提供​​解決方案。

和

SMB是Windows機器內置的，它提供了一些其他機制（如VirtualBox共享文件夾）的更高性能替代方案。

有關額外信息，請參閱Vagrant共享文件夾基准 。

Answer 2

waitpid的聯機幫助頁說：waitpid（）系統調用暫停執行調用進程，直到pid參數指定的子進程發生更改狀態。 默認情況下，waitpid（）僅等待已終止的子項，但此行為可通過options參數進行修改，如下所述。 http://linux.die.net/man/2/waitpid

為什么兒童過程改變國家需要這么長時間？ django manage.py runserver命令是一個非常薄的包裝器，超過了另一個runserver命令：

 2533 pts/0    Ss     0:00  \_ bash
28374 pts/0    S+     0:00  |   \_ ../env/bin/python ./manage.py runserver
 7968 pts/0    Sl+   20:26  |       \_/home/sandford/workspace/usgm_apps/usgm_apps/../env/bin/python ./manage.py runserver

所以“老板”（28374）注意到文件的變化並告訴“工人”（7968）退出。 一旦“worker”退出，它就會使用新的源文件啟動一個新的worker。 “工人”需要很長時間才能退出。

或者OSX認為它需要很長時間才能退出。 如果由於某種原因操作系統在內核中進行簿記並延遲更新狀態，那么最終可能會出現這樣的延遲。

或者也許還有其他事情要發生。 這令人困惑。

Answer 3

在我的例子中，它是由在wsgi.py文件中加載DjangoWhiteNoise模塊引起的。 在我添加了在我的開發環境中禁用模塊的條件后，服務器重新加載時間大幅減少。