J'ai Django en cours d'exécution à Apache via mod_wsgi. Je crois que Django met en cache mon côté du serveur de pages, ce qui provoque une partie de la fonctionnalité de ne pas fonctionner correctement.
J'ai un compte à rebours qui fonctionne en obtenant l'heure du serveur actuel, déterminant le temps de comptage restant et émettre ce numéro au modèle HTML. Une minuterie de compte à rebours JavaScript prend ensuite la relève et exécute le compte à rebours pour l'utilisateur.
Le problème se pose lorsque l'utilisateur rafraîchit la page ou navigue sur une page différente avec le compte à rebours. La minuterie semble sauter à des moments différents sporadiquement, revenant généralement à la même heure et encore sur chaque rafraîchissement.
Utilisation de httpfox, la page n'est pas chargée à partir de mon cache de navigateur. Il ressemble donc à Django ou à Apache la mise en cache de la page. Y a-t-il un moyen de désactiver cette fonctionnalité? Je ne vais pas avoir assez de trafic pour vous soucier de la mise en cache de la sortie du script. Ou est-ce que je me trompe complètement pourquoi cela se produit?
[modifier] à partir des messages ci-dessous, il semble que la mise en cache est désactivée à Django, ce qui signifie qu'il doit se produire ailleurs, peut-être dans Apache?
[modifier] J'ai une description plus détaillée de ce qui se passe: pour les 7 premières demandes apportées au serveur, les pages sont rendues par le script et renvoyées, bien que chacune de ces 7 pages semble être mis en cache comme 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.
[modifier] J'ai configuré mod_wsgi pour exécuter un seul processus à la fois, ce qui entraîne la réinitialisation de la minuterie à la même valeur dans tous les cas. Fait intéressant cependant, il existe un autre composant sur ma page qui affiche une image aléatoire sur chaque demande, à l'aide de la commande ('? »), Et qui vous rafraîchit avec différentes images chaque fois, ce qui indiquerait que la mise en cache se produit dans Django et non à Apache.
[EDIT] À la lumière de l'édition précédente, je suis retourné et a examiné le fichier de vues correspondant.py, constatant que la variable de démarrage du compte à rebours était définie globalement dans le module, en dehors des fonctions de vue. Le déplacement de ce réglage à l'intérieur des fonctions de vue résolut le problème. Donc, il s'est avéré de ne pas être un problème de mise en cache après tout. Merci à tout le monde pour votre aide à ce sujet.
4 Réponses :
Avez-vous spécifiquement configuré Django Caching? Depuis les documents, il semble que vous sachiez clairement si Django mettait la mise en cache car elle nécessite un travail à l'avance pour le faire fonctionner. Plus précisément, vous devez définir où les fichiers mis en cache sont enregistrés.
Je n'ai fait aucun de ce travail préliminaire, alors je suppose que la cache Django est handicapée ... toutes idées sur quoi d'autre pourrait causer la question avec l'heure de début de la minuterie? Est-ce que Apache avec mod_wsgi pourrait-il faire cela?
De mon expérience avec mod_wsgi à Apache, il est très peu probable qu'ils causent la mise en cache. Quelques choses à essayer:
Je suis d'accord. C'est probablement Apache ou votre fournisseur de services Internet faisant la mise en cache.
1. Le site est en cours d'exécution sur un serveur sur notre réseau local. Il n'y a donc pas de proxy. 2. Middleware_Classes = ('django.middleware.common.commonmiddleware', 'django.contrib.sessions.middleware.sessions.middlewrab.sessions.middleware', 'django.contrib.ath.middleware.authentisticationmiddleware ",) 3. Aucun de ces termes n'apparaît dans le code. 4. Non 5. Redémarrer Apache Effacer le problème et rafraîchit le cache à une nouvelle valeur.
Utilisez-vous une configuration multiprocessée pour Apache / Mod_WSGI? Si vous êtes, cela expliquera pourquoi différentes réponses peuvent avoir une valeur différente pour la minuterie, probablement que lorsque la minuterie est initialisée sera différente pour chaque processus de traitement des processus. Ainsi, pourquoi cela peut sauter.
avoir une lecture de:
http://code.google.com/p/modwsgi/wiki/processesandthraire
Travailler dans quel mode ou configuration vous exécutez Apache / MOD_WSGI et post peut-être que cette configuration est. Sans savoir, il y a trop d'inconnues.
httpd -V montre que le MPM de la préforce est utilisé. Fileté: Non, Forked: Oui (Nombre de processus variables)
Ensuite, des demandes distinctes peuvent être traitées par différents processus. Ces processus peuvent donc avoir des vues distinctes de données. Aussi lue ' blog.dscpl.com .au / 2009/03 / ... 'Pour les dangers de l'utilisation de la préfigue avec mod_python et mod_wsgi.
Cela semble être ce qui se passe. J'ai changé la configuration pour exécuter en mode Daemon, limitant le nombre de processus à un, ce qui l'a limitée à une seule version mise en cache de la page. Donc, ma minuterie se réinitialise à la même valeur sur chaque demande. C'est malheureusement toujours pas le comportement souhaité cependant.
Je viens de tomber sur ceci:
djangobook.com/fr/2.0/Chapter15