Comment désactiver le cache de page Django/mod_WSGI

Question

J'ai Django en cours d'exécution dans Apache via mod_wsgi. Je crois que Django met en cache mes pages côté serveur, ce qui provoque certaines fonctionnalités à ne pas fonctionner correctement.

J'ai un compte à rebours qui fonctionne en obtenant l'heure actuelle du serveur, en déterminant le temps de compte à rebours restant, et en fournissant ce nombre au modèle HTML. Un compte à rebours javascript prend alors le relais et exécute le compte à rebours pour l'utilisateur.

Le problème survient lorsque l'utilisateur actualise la page ou navigue vers une autre page avec le compte à rebours. La minuterie semble sauter sporadiquement à différents moments, revenant généralement à la même heure encore et encore à chaque rafraîchissement. En utilisant HTTPFox, la page n'est pas chargée depuis le cache de mon navigateur, donc il semble que Django ou Apache mettent en cache la page. Est-il possible de désactiver cette fonctionnalité? Je ne vais pas avoir assez de trafic pour m'inquiéter de la mise en cache de la sortie du script. Ou ai-je complètement tort de savoir pourquoi cela se passe? [Modifier] Dans les articles ci-dessous, il semble que la mise en cache soit désactivée dans Django, ce qui signifie que cela doit se produire ailleurs, peut-être dans Apache?

[Modifier] J'ai une description plus complète de ce qui se passe: Pour les 7 premières demandes faites au serveur, les pages sont rendues par le script et retournées, bien que chacune de ces 7 pages semble être mis en cache car il apparaît plus tard. Sur la 8ème demande, le serveur sert la première page. Sur la 9ème demande, il sert la deuxième page, et ainsi de suite dans un cycle. Cela dure jusqu'à ce que je redémarre Apache, lorsque le processus recommence. [Edit] J'ai configuré mod_wsgi pour qu'il n'exécute qu'un seul processus à la fois, ce qui a pour effet de réinitialiser la minuterie à la même valeur dans tous les cas. Il est intéressant de noter qu'un autre composant de ma page affiche une image aléatoire à chaque requête, en utilisant order ('?'), Qui rafraîchit chaque fois différentes images, ce qui indiquerait que la mise en cache se passe dans Django et non dans Apache. [Edit] À la lumière de l'édition précédente, je suis retourné et ai examiné le fichier views.py approprié, trouvant que la variable de début de compte à rebours a été établie globalement dans le module, en dehors des fonctions d'affichage. Le déplacement de ce paramètre dans les fonctions de vue a résolu le problème. Donc, il s'est avéré ne pas être un problème de mise en cache après tout. Merci à tous pour votre aide à ce sujet.

Answer 1

De mon expérience avec mod_wsgi dans Apache, il est très peu probable qu'ils causent la mise en cache. Un couple de choses à essayer:

1. Il est possible que vous avez une proxy server entre votre ordinateur et le serveur Web qui est mise en cache de façon appropriée ou inappropriée pages. Parfois, les FAI exécutent des serveurs proxy pour réduire la bande passante en dehors de leur réseau. Pouvez-vous s'il vous plaît fournir les en-têtes HTTP pour une page qui est mise en cache (Firebug peut vous les donner). Les en-têtes que je serais particulièrement intéressé incluent Cache-Control, Expires, Last-Modified et ETag.
2. Pouvez-vous publier votre MIDDLEWARE_CLASSES à partir de votre fichier settings.py? Il est possible que vous ayez un intergiciel qui effectue la mise en cache pour vous.
3. Pouvez-vous grep votre code pour les éléments suivants "charger cache", "django.core.cache" et "cache_page". Un * grep -R "recherche" ** fonctionnera.
4. Est-ce que settings.py (ou tout ce qu'il importe comme "from localsettings import *") inclut CACHE_BACKEND? Que se passe-t-il lorsque vous redémarrez apache? (par exemple sudo services apache restart). Si un redémarrage efface le problème, alors il peut être apache de faire une mise en cache (il est possible que cela puisse également effacer un backend de cache Django)

Answer 2

Avez-vous spécifiquement installé la mise en cache de Django? D'après les docs, il semblerait que vous sachiez clairement si Django était en cache car cela nécessite un travail préalable pour que cela fonctionne. Plus précisément, vous devez définir l'emplacement d'enregistrement des fichiers mis en cache.

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

Answer 3

Utilisez-vous une configuration multiprocess pour Apache/mod_wsgi? Si tel est le cas, cela expliquera pourquoi les différentes réponses peuvent avoir une valeur différente pour le temporisateur, car il est probable que lorsque le temporisateur est initialisé, cela sera différent pour chaque requête de traitement de processus. Alors pourquoi ça peut sauter.

avoir une lecture de:

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

travail dans quel mode ou la configuration que vous exécutez Apache/mod_wsgi et postez peut-être ce que la configuration est. Sans le savoir, il y a trop d'inconnues.

Answer 4

Je viens suis tombé sur ceci:

Prise en charge automatique Rechargement Pour aider les outils de déploiement, vous pouvez activer le support pour le rechargement automatique. Chaque fois que quelque chose change le fichier .wsgi, mod_wsgi rechargera tous les processus du démon pour nous.

Pour cela, il suffit d'ajouter la directive suivante à votre section Répertoire:

WSGIScriptReloading On