Przyspieszenie ładowania pierwszej strony w django

Question

Po aktualizacji kodu na mojej stronie internetowej (oczywiście) ponownie uruchamiam instancję apache, aby zmiany zostały wprowadzone.

Niestety pierwsza strona obsługiwana przez każdą instancję Apache jest dość powolna, gdy ładuje wszystko do pamięci RAM po raz pierwszy (5-7 sekund dla tej konkretnej witryny).

Kolejne prośby trwają tylko 0,5 - 1,5 sekundy, więc chciałbym wyeliminować ten efekt dla moich użytkowników.

Czy istnieje lepszy sposób, aby wszystko załadowane do pamięci RAM niż zrobić wget x razy (gdzie x to liczba wystąpień apache zdefiniowanych przez ServerLimit w moim http.conf)

napisanie skryptu restartu restartujący Apache i działa wget 5 razy wydaje mi się trochę hacky.

Dzięki!

Answer 1

Domyślną Apache/mod_wsgi jest tylko kod aplikacji obciążenie na pierwsze żądanie do procesu, który wymaga, aby aplikacje. Pierwszym krokiem jest więc skonfigurowanie mod_wsgi do wstępnego załadowania kodu po uruchomieniu procesu, a nie tylko do pierwszego żądania. Można to zrobić w mod_wsgi 2.X za pomocą dyrektywy WSGIImsportScript.

Zakładając tryb demona, który jest lepszym rozwiązaniem i tak, oznacza to, że masz coś takiego:

# Define process group. 

WSGIDaemonProcess django display-name=%{GROUP} 

# Mount application. 

WSGIScriptAlias//usr/local/django/mysite/apache/django.wsgi 

# Ensure application preloaded on process start. Must specify the 
# process group and application group (Python interpreter) to use. 

WSGIImportScript /usr/local/django/mysite/apache/django.wsgi \ 
    process-group=django application-group=%{GLOBAL} 

<Directory /usr/local/django/mysite/apache> 

    # Ensure application runs in same process group and application 
    # group as was preloaded into on process start. 

    WSGIProcessGroup django 
    WSGIApplicationGroup %{GLOBAL} 

    Order deny,allow 
    Allow from all 
</Directory> 

Po dokonaniu zmiany kodu, zamiast dotyku plik skryptu WSGI, co jest sprawdzane tylko na następne żądanie, zamiast tego wyślij sygnał SIGINT do procesów w grupie procesów demona.

Za pomocą opcji "display-name" do WSGIDaemonProcess można zidentyfikować procesy przy użyciu programu "ps" w stylu BSD. Przy "display-name" ustawionym na "% {GROUP}", wynik "ps" powinien pokazywać "(wsgi: django)" jako nazwę procesu. Zidentyfikuj identyfikator procesu i wykonaj:

kill -SIGINT pid 

Zamień "pid" z rzeczywistym identyfikatorem procesu. Jeśli więcej niż jeden proces w grupie procesów demona, wyślij sygnał do wszystkich z nich.

Nie wiem, czy można użyć "killall" w jednym kroku. Miałem problemy ze robi to na MacOS X.

W mod_wsgi 3.X konfiguracja może być prostsze i można używać zamiast:

# Define process group. 

WSGIDaemonProcess django display-name=%{GROUP} 

# Mount application and designate which process group and 
# application group (Python interpreter) to run it in. As 
# process group and application group named, this will have 
# side effect of preloading application on process start. 

WSGIScriptAlias//usr/local/django/mysite/apache/django.wsgi \ 
    process-group=django application-group=%{GLOBAL} 

<Directory /usr/local/django/mysite/apache> 
    Order deny,allow 
    Allow from all 
</Directory> 

Oznacza to, że nie ma potrzeby stosowania oddzielnej dyrektywy WSGIImportScript jako specyficznego procesu może grupa i grupa aplikacji jako argumenty do WSGIScriptAlias ​​zamiast z efektem ubocznym, że wstępnie załaduje aplikację.

Answer 2

Jak działa Django (mod_python vs mod_wsgi)?

Jeśli używasz mod_wsgi (w trybie demona), ponowne uruchomienie Apache nie jest konieczne do przeładowania aplikacji. Wszystko, co musisz zrobić, to zaktualizować mtime skryptu wsgi (co jest łatwe z touch). Dokumentacja

mod_wsgi zawiera dość dokładnego wyjaśnienia procesu:

ReloadingSourceCode