2009-10-27 7 views
9

Mam Django działającego w Apache przez mod_wsgi. Uważam, że Django buforuje moje strony po stronie serwera, co powoduje, że niektóre funkcje nie działają poprawnie.Jak wyłączyć Django/mod_WSGI Buforowanie stron

Mam zegar odliczający, który działa, pobierając bieżący czas serwera, określając pozostały czas odliczania i wyświetlając ten numer w szablonie HTML. Odliczanie czasu javascript następnie przejmuje i uruchamia odliczanie dla użytkownika.

Problem powstaje, gdy użytkownik odświeża stronę lub przechodzi na inną stronę z zegarem odliczającym. Czasomierz wydaje się skakać do różnych czasów sporadycznie, zwykle wracając do tego samego czasu w kółko po każdym odświeżeniu.

Przy użyciu HTTPFox strona nie jest ładowana z pamięci podręcznej przeglądarki, więc wygląda na to, że Django lub Apache buforuje stronę. Czy istnieje sposób wyłączenia tej funkcji? Nie będę mieć wystarczająco dużo ruchu, aby martwić się buforowaniem danych wyjściowych skryptu. Czy całkowicie błędnie rozumiem, dlaczego tak się dzieje?

[Edytuj] Z postów poniżej wygląda na to, że buforowanie jest wyłączone w Django, co oznacza, że ​​musi się zdarzyć gdzie indziej, być może w Apache?

[Edytuj] Mam dokładniejszy opis tego, co się dzieje: W przypadku pierwszych 7 (lub mniej) żądań wysłanych do serwera, strony są renderowane przez skrypt i zwracane, chociaż każda z tych 7 stron wydaje się być być zbuforowane, jak pokazuje później. W ósmym żądaniu serwer wyświetla pierwszą stronę. W dziewiątym żądaniu podaje drugą stronę i tak dalej w cyklu. Trwa to do czasu ponownego uruchomienia apache, kiedy proces zaczyna się od nowa.

[Edytuj] Skonfigurowałem mod_wsgi do uruchamiania tylko jednego procesu na raz, co powoduje, że zegar resetuje się do tej samej wartości w każdym przypadku. Interesujące jest jednak to, że na mojej stronie znajduje się inny komponent, który wyświetla losowy obraz na każdym żądaniu, używając polecenia ("?"), I który odświeża za każdym razem różne obrazy, co wskazuje, że buforowanie odbywa się w Django, a nie w Apache.

[Edytuj] W świetle poprzedniej edycji, wróciłem i przejrzałem odpowiedni plik views.py, stwierdzając, że zmienna startowa odliczania była ustawiana globalnie w module, poza funkcjami widoku. Przesunięcie tego ustawienia wewnątrz funkcji widoku rozwiązało problem. W końcu okazało się, że nie jest to kwestia buforowania. Dziękuję wszystkim za pomoc w tej sprawie.

+0

http://www.djangobook.com/en/2.0/chapter15/ – cwallenpoole

Odpowiedz

6

Z mojego doświadczenia z mod_wsgi w Apache, to jest wysoce prawdopodobne, że są one przyczyną buforowania. Kilka rzeczy, aby spróbować:

  1. Jest możliwe, że masz jakiś proxy server między komputerem a serwerem internetowym, który jest właściwie lub niewłaściwie buforowanie stron. Czasami usługodawcy internetowi uruchamiają serwery proxy, aby zmniejszyć przepustowość poza swoją siecią. Czy możesz podać nagłówki HTTP dla strony, która jest buforowana (Firebug może ci je przekazać). Nagłówki, które szczególnie mnie interesują obejmują Cache-Control, Expires, Last-Modified i ETag.
  2. Czy możesz opublikować MIDDLEWARE_CLASSES z pliku settings.py. Możliwe, że masz oprogramowanie pośrednie, które wykonuje dla ciebie buforowanie.
  3. Czy możesz pobrać kod dla następujących elementów "load cache", "django.core.cache" i "cache_page". A * grep -R "search" ** zadziała.
  4. Czy plik settings.py (lub coś, co importuje jak "from localsettings import *") zawiera CACHE_BACKEND?
  5. Co stanie się po zrestartowaniu apache? (np. restart usługi apache sudo). Jeśli ponowne uruchomienie rozwiąże problem, może to być apache, który robi buforowanie (możliwe, że może to również usunąć mechanizm zarządzania pamięcią podręczną Django)
+0

Zgadzam się. To prawdopodobnie Apache lub twój ISP robi buforowanie. –

+0

1. Witryna działa obecnie na serwerze w naszej sieci lokalnej, więc nie ma serwera proxy. 2. MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware' 'django.contrib.sessions.middleware.SessionMiddleware' 'django.contrib.auth.middleware.AuthenticationMiddleware' ) 3. Żadna te terminy pojawiają się w dowolnym miejscu kodu. 4. Nie 5. Ponowne uruchomienie Apache usuwa problem i odświeża pamięć podręczną o nowej wartości – Travis

1

Czy specjalnie skonfigurowałeś buforowanie Django? Z dokumentacji wydaje się, że wyraźnie wiedziałbyś, czy Django buforował, ponieważ wymaga wcześniejszej pracy, aby to działało. W szczególności musisz określić miejsce zapisania buforowanych plików.

http://docs.djangoproject.com/en/dev/topics/cache/

+0

nie zrobiłem nic z tego wstępna praca, więc domyślam się, że buforowanie Django jest wyłączone ... Jakieś pomysły, co jeszcze może być przyczyną problemu z czasem uruchamiania timera? Czy apache z mod_wsgi może to zrobić? – Travis

1

Czy używasz konfiguracji wieloprocesowej dla Apache/mod_wsgi? Jeśli tak, to będzie wyjaśniać, dlaczego różne odpowiedzi mogą mieć inną wartość dla timera, ponieważ prawdopodobieństwo, że timer zostanie zainicjowany, będzie różne dla każdego żądania obsługi procesu. Więc dlaczego może się skakać.

Mają lektury:

http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

poćwiczyć w jakim trybie lub konfiguracji używasz Apache/mod_wsgi i może pisać, co to jest konfiguracja. Bez wiedzy istnieje zbyt wiele niewiadomych.

+0

httpd -V pokazuje, że używany jest prefork MPM. threaded: no, forked: yes (zmienna liczba procesów) – Travis

+0

Następnie oddzielne żądania mogą być obsługiwane przez różne procesy, dzięki czemu procesy te mogą mieć różne widoki danych. Przeczytaj także "http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html" dla niebezpieczeństw związanych z używaniem prefork z mod_python i mod_wsgi. –

+0

To wydaje się być tym, co się dzieje. Zmieniłem konfigurację tak, aby działała w trybie Daemona, ograniczając liczbę procesów do jednego, co ograniczyło ją do tylko jednej buforowanej wersji strony. Tak więc mój zegar resetuje się do tej samej wartości dla każdego żądania. Niestety nie jest to nadal pożądane zachowanie. – Travis

2

Właśnie natknąłem to:

Wsparcie dla automatycznego przeładowanie Aby pomóc wdrażania narzędzi można aktywować obsługę automatycznego ponownego załadunku. Ilekroć coś zmieni pliku .wsgi, mod_wsgi przeładuje dla nas wszystkie procesy demona.

Do tego wystarczy dodać następującą dyrektywę do sekcji klasyfikacji:

WSGIScriptReloading On 
+1

To jest domyślnie włączone, więc nie powinieneś się o to martwić. Sposób obsługi ponownego ładowania opisano w http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode –

+2

Nie wiem - ale mogę powiedzieć, że używam wsgi na dwóch różnych komputerach - jednym z obszerną witryną opartą na Django (OpenStack Dashboard/Horizon) i jedną z moim własne prostsze skrypty - i włączanie WSGIScriptReloading na każdym zrobionym to tak, kiedy modyfikowałem skrypty - modyfikacje odniosłyby skutek przy ponownym ładowaniu następnej strony bez konieczności restartowania Apache. – Brad

+1

Cóż, mogę powiedzieć, że napisałem mod_wsgi, a kod ma go domyślnie. Jak wyjaśniono w tym dokumencie, który łączyłem, dla trybu wbudowanego w sam plik skryptu WSGI jest ponownie ładowany, a nie cały kod aplikacji. Powinieneś dokładnie sprawdzić, czy w rzeczywistości używasz trybu embedded lub trybu demona, jak opisuje ten dokument. Bardzo często ludzie nie mają dyrektywy WSGIProcessGroup i nie używają trybu demona, tak jak myślą. –