Comment mesurer les performances du cache Django?

Question

J'ai un site Web plutôt petit (environ 4,5 000 pages vues par jour) fonctionnant sur Django, avec PostgreSQL 8.3 comme base de données.

J'utilise la base de données en tant que cache et backend de la session. J'ai entendu beaucoup de bonnes choses à propos de l'utilisation de Memcached à cette fin, et j'aimerais certainement l'essayer. Cependant, j'aimerais savoir exactement quels seraient les avantages d'un tel changement: j'imagine que mon site n'est peut-être pas assez grand pour que le meilleur système de cache cache puisse faire la différence. Le fait est que ce ne serait pas moi qui installerais et configurer memcached, et je ne voudrais pas perdre du temps à quelqu'un pour rien ou très peu.

Comment puis-je mesurer la surcharge introduite en utilisant la base de données en tant que moteur de cache? J'ai consulté la barre d'outils django-debug-tool, mais si je comprends bien, ce n'est pas quelque chose que vous aimeriez mettre sur un site de production (vous devez définir DEBUG = True pour que cela fonctionne ). Malheureusement, je ne peux pas tout à fait reproduire les paramètres de production sur mon ordinateur portable (mon système d'exploitation, mon processeur et beaucoup plus de RAM).

Quelqu'un at-il comparé différents backends de cache / session Django? Quelqu'un sait-il quelle serait la différence de performances si je faisais, par exemple, une session d'écriture sur chaque demande?

Answer 1

Lors de mon travail précédent, nous avions essayé de mesurer l’impact de la mise en cache sur le site que nous développions. Sur la même machine, nous avons testé en charge l'ensemble des 10 pages les plus couramment utilisées comme pages de début (listes d'objets), ainsi que des pages de détail d'objet prises au hasard dans le pool de ~ 200000. La différence était de 150 requêtes / seconde à 30000 requêtes / seconde et les requêtes de la base de données ont été réduites à 1-2 par page.

Qu'est-ce qui a été mis en cache:

• sessions
• listes d'objets récupérées pour chaque page individuelle dans la liste d'objets
• objets secondaires et contenu commun (trouvés sur chaque page)
• listes de catégories d'objets et autres propriétés de catégorisation
• compteurs d'objets (calculés hors ligne par le travail cron)
• objets individuels

En général, nous avons utilisé uniquement la mise en cache granulaire de bas niveau, pas la structure de cache de haut niveau. Cela nécessitait une conception très soignée (le cache devait être correctement invalidé à chaque changement d'état de la base de données, comme pour ajouter ou modifier un objet).

Answer 2

Le projet DiskCache publie Tests d'évaluation du cache Django comparant la mémoire locale, Memcached, Redis, basée sur le fichier, et diskcache.DjangoCache . Un avantage supplémentaire de DiskCache est qu'aucun processus séparé n'est nécessaire (contrairement à Memcached et Redis). Au lieu de cela, les clés de cache et les petites valeurs sont mappées en mémoire dans la mémoire du processus Django. La récupération des valeurs du cache est généralement plus rapide que Memcached sur localhost. Un certain nombre de paramètres contrôlent la quantité de données. gardé en mémoire; le reste étant paginé sur le disque.

Answer 3

Réponse courte: Si vous avez assez de mémoire vive, memcached sera toujours plus rapide. Vous ne pouvez pas vraiment comparer le cache memcached ou le cache de base de données, mais gardez à l’esprit que le gros goulet d’étranglement avec les serveurs est l’accès au disque, en particulier l’accès en écriture.

Quoi qu'il en soit, le cache disque est préférable si vous avez plusieurs objets à mettre en cache et une date d'expiration longue. Mais dans cette situation, si vous voulez des performances de concert, il est préférable de générer vos pages de manière statique avec un script python et de les livrer avec ligthtpd ou nginx.

Pour memcached, vous pouvez ajuster la quantité de RAM dédiée au serveur.

Answer 4

Essayez-le. Utilisez firebug ou un outil similaire et exécutez memcache avec un peu d’allocation de RAM (64 Mo, par exemple) sur le serveur de test.

Marquez vos résultats de chargement moyens vus dans firebug sans memcache, puis activez la mise en cache et marquez les nouveaux résultats. C'est aussi simple que cela a été dit.

Les résultats choquent généralement les gens, car les performances se soulèvent très bien.

Answer 5

Utilisez la la barre d'outils django-debug-tool pour voir combien de temps a été économisé. requête SQL