Przeładowanie serwera deweloperskiego Django trwa zbyt długo

Question

To był mój problem od czasu aktualizacji do wersji OSX Lion: Ilekroć runserver ładuje się po zmianie pliku w moim projekcie Django, zanim zacznie ponownie wyświetlać, minie sporo czasu.

Zdarza się to nawet w nowo utworzonym projekcie Django 1.4. Nie miał tego problemu na Snow Leopard.

użyłem cProfile a to gdzie spędził większość swojego czasu:

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} 
    ... 

Ale nie rozumiem dlaczego?

Answer 1

Strona podręczna dla waitpid mówi: Funkcja systemowa waitpid() zawiesza wykonywanie procesu wywołującego, dopóki nie zostanie zmieniony stan podrzędny określony przez argument pid. Domyślnie waitpid() czeka tylko na zakończone elementy podrzędne, ale zachowanie to można modyfikować za pomocą argumentu options, jak opisano poniżej. http://linux.die.net/man/2/waitpid

Dlaczego proces potomny trwa tak długo? Komenda Django manage.py runserver jest bardzo cienka owijka na inne polecenie 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 

więc „boss” (28374) zauważy zmianę na pliku i mówi „pracownik” (7968), aby wyjść. Po wyjściu "worker" uruchamia nowy robot z nowymi plikami źródłowymi. "Pracownik" zabiera dużo czasu.

Lub OSX ROZMAWIA, że wyjście z niego zajmuje dużo czasu. Jeśli system operacyjny zapisze się w księgowości w jądrze z jakiegoś powodu i opóźni stan aktualizacji, może dojść do takiego opóźnienia.

A może dzieje się coś zupełnie innego. To kłopotliwe.

Answer 2

(dla facetów nadal googlowania odpowiedź)

miałem podobny problem przy użyciu Vagrant (na komputerze hosta w systemie Windows). Rozwiązaniem dla mnie było przeniesienie folderu virtualenv z dala od zsynchronizowanej wersji /vagrant. Domyślne ustawienia zsynchronizowanych folderów używają dostawcy VirtualBox i to jest problem. Możemy przeczytać o tym w kolejnych metod synchronizacji z Vagrant official documentation:

w niektórych przypadkach wspólne implementacje domyślne foldery (takie jak VirtualBox udostępnione foldery) mają kar wysokiej wydajności. Jeśli widzisz mniej niż idealną wydajność w przypadku zsynchronizowanych folderów, NFS może zaoferować rozwiązanie.

i

SMB jest wbudowany w komputerach z systemem Windows i zapewnia wyższą wydajność alternatywę do innych mechanizmów, takich jak VirtualBox folderów współdzielonych.

Aby uzyskać dodatkowe informacje, patrz Vagrant shared folders benchmark.