문제

나는 mod_wsgi를 통해 Apache에서 Django를 실행하고 있습니다. Django가 내 페이지를 서버 사이드로 캐싱하고 있다고 생각합니다. 이로 인해 일부 기능이 올바르게 작동하지 않습니다.

현재 서버 시간을 얻고 나머지 카운트 다운 시간을 결정하고 해당 숫자를 HTML 템플릿에 출력하여 작동하는 카운트 다운 타이머가 있습니다. 그런 다음 JavaScript 카운트 다운 타이머가 사용자의 카운트 다운을 수행하고 실행합니다.

사용자가 페이지를 새로 고치거나 카운트 다운 타이머로 다른 페이지로 탐색 할 때 문제가 발생합니다. 타이머는 산발적으로 다른 시간으로 뛰어 다니는 것처럼 보이며, 일반적으로 각 새로 고침에서 동시에 반복해서 돌아갑니다.

httpfox를 사용하면 페이지가 내 브라우저 캐시에서로드되지 않으므로 Django 또는 Apache가 페이지를 캐싱하는 것처럼 보입니다. 이 기능을 비활성화하는 방법이 있습니까? 스크립트 출력 캐싱에 대해 걱정할 수있는 트래픽이 충분하지 않을 것입니다. 아니면 왜 이런 일이 일어나고 있는지에 대해 완전히 틀렸습니까?

편집] 아래 게시물에서 Django에서 캐싱이 비활성화 된 것처럼 보입니다. 즉, 아마도 Apache에서 다른 곳에서 일어나야합니까?

편집] 무슨 일이 일어나고 있는지에 대한 자세한 설명이 있습니다. 서버에 처음 제기 된 7 개 (또는 그) 요청에 대해 페이지는 스크립트에 의해 렌더링되고 반환됩니다. 나중에 나타납니다. 8 번째 요청에서 서버는 첫 페이지를 제공합니다. 9 번째 요청에서 두 번째 페이지를 제공하는 등의주기에서 제공됩니다. 프로세스가 다시 시작될 때 Apache를 다시 시작할 때까지 지속됩니다.

편집] MOD_WSGI를 한 번에 하나의 프로세스 만 실행하도록 구성되어있어 타이머가 모든 경우에 동일한 값으로 재설정됩니다. 흥미롭게도, 내 페이지에는 주문 ( '?')을 사용하여 각 요청에 임의의 이미지를 표시하는 또 다른 구성 요소가 있으며 매번 다른 이미지로 새로 고침을 제공하는데, 이는 캐싱이 아파치가 아닌 Django에서 발생하고 있음을 나타냅니다.

EDIT] 이전 편집에 비추어 볼 때, 나는 관련보기를 검토하여 Countdown Start Variable이 View Functions 외부 모듈에서 전 세계적으로 설정되고 있음을 발견했습니다. 보기 기능 내부에서 해당 설정을 이동하면 문제가 해결되었습니다. 그래서 그것은 결국 캐싱 문제가되지 않은 것으로 판명되었습니다. 이에 대한 도움을 주셔서 감사합니다.

도움이 되었습니까?

해결책

Apache의 mod_wsgi에 대한 나의 경험을 통해, 그들이 캐싱을 일으킬 가능성은 거의 없습니다. 시도해야 할 몇 가지 사항 :

  1. 당신이 약간있을 수 있습니다 프록시 서버 컴퓨터와 웹 서버 사이에 적절하거나 부적절하게 캐싱되는 웹 서버. 때때로 ISP는 프록시 서버를 실행하여 네트워크 외부의 대역폭을 줄입니다. 캐시 된 페이지에 HTTP 헤더를 제공 할 수 있습니까 (Firebug가이를 제공 할 수 있음). 내가 구체적으로 관심이있는 헤더에는 캐시 제어, 만료, 최후의 수정 및 ETAG가 포함됩니다.
  2. settings.py 파일에서 middleware_classes를 게시 할 수 있습니까? 캐싱을 수행하는 미들웨어가있을 수 있습니다.
  3. 다음 항목 "로드 캐시", "django.core.cache"및 "cache_page"에 대한 코드를 방목 할 수 있습니까? a *grep -r "검색"**가 작동합니다.
  4. settings.py (또는 "localsettings import *"에서 가져 오는 것이 Cache_backend가 포함되어 있습니까?
  5. Apache를 다시 시작하면 어떻게됩니까? (예 : Sudo Services Apache Restart). 다시 시작하면 문제가 해결되면 Apache가 캐싱을 수행 할 수 있습니다 (Locmen Django Cache 백엔드를 제거 할 수 있습니다).

다른 팁

방금 이것을 발견했습니다.

자동 재 장전 지원 배포 도구를 지원하기 위해 자동 재 장전에 대한 지원을 활성화 할 수 있습니다. .wsgi 파일이 변경 될 때마다 Mod_wsgi는 모든 데몬 프로세스를 다시로드합니다.

이를 위해서는 디렉토리 섹션에 다음 지침을 추가하십시오.

WSGIScriptReloading On

Django 캐싱을 구체적으로 설정 했습니까? 문서에서 Django가 작동하기 위해 미리 작업이 필요하기 때문에 캐싱 중인지 분명히 알 수 있습니다. 특히 캐시 된 파일이 저장된 위치를 정의해야합니다.

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

Apache/mod_wsgi에 멀티 프로세스 구성을 사용하고 있습니까? 당신이 있다면, 이는 타이머가 초기화 될 때 각 프로세스 처리 요청에 대해 다른 응답이 타이머에 대해 다른 값을 가질 수있는 이유를 설명합니다. 따라서 왜 뛰어들 수 있습니다.

다음을 읽으십시오.

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

Apache/Mod_wsgi를 실행하는 모드 또는 구성에서 운동하고 해당 구성이 무엇인지 게시하십시오. 알지 못하면 미지수가 너무 많습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top