Django inclut un framework de mise en cache flexible prenant en charge plusieurs niveaux de mise en cache (pages entières, résultats de vue, fragments de template, ou données arbitraires) et plusieurs backends (en mémoire, Redis, Memcached, base de données). La mise en cache évite de répéter des tâches coûteuses — l'une des optimisations de performance à plus fort impact.
CACHES = {
: {
: ,
: ,
}
}
# 1. Per-view caching — cache an entire view's output
from django.views.decorators.cache import cache_page
@cache_page(60 * 15) # cache this view's response for 15 minutes
def article_list(request):
...
<!-- 2. Template fragment caching — cache part of a template -->
{% load cache %}
{% cache 500 sidebar %}
... expensive sidebar rendering ... <!-- cached for 500 seconds -->
{% endcache %}
# 3. Low-level cache API — cache ANY data, full control
from django.core.cache import cache
def get_stats():
stats = cache.get("dashboard_stats") # check cache first
if stats is None: # cache MISS
stats = compute_expensive_stats() # do the work
cache.set("dashboard_stats", stats, 3600) # store for 1 hour
return stats
Django vous permet de mettre en cache à plusieurs granularités : pages entières (cache_page), fragments de template ({% cache %}), et données arbitraires via l'API bas niveau (cache.get/cache.set — le pattern flexible get-or-compute). Il y a aussi la mise en cache à l'échelle du site via middleware.
# when underlying data changes, the cache must be updated or cleared, or users see stale data
def update_article(article):
article.save()
cache.delete("article_list") # invalidate affected cache entries
# strategies: TTL (accept brief staleness), explicit deletion on writes, versioned keys,
# or signals to invalidate on model save/delete
Cache invalidation is the classic hard problem: when data changes, stale cached
values must be cleared/refreshed. Approaches: short TTLs (accept some staleness),
explicit cache.delete on writes, or cache versioning/key schemes.
✓ Expensive queries/computations, rendered pages/fragments that change infrequently
✓ Aggregations, external API responses, session data
✗ Highly personalized or rapidly-changing data (or use very short TTLs / vary per user)
✗ Don't cache sensitive data carelessly (consider who can read the cache)
La mise en cache est l'une des optimisations de performance à plus fort impact pour les applications Django, et le système de mise en cache multi-niveaux comprehensive du framework le rend accessible — le comprendre est une connaissance précieuse de niveau senior pour construire des applications rapides et scalables.
La valeur fondamentale est d'éviter les tâches coûteuses répétées : les requêtes de base de données, les calculs complexes, les appels d'API externes et le rendu de template peuvent être mis en cache pour que les requêtes suivantes soient servies rapidement, réduisant dramatiquement la latence et la charge de la base de données/serveur.
La flexibilité de Django sur plusieurs niveaux de mise en cache (pages entières avec cache_page, fragments de template avec {% cache %}, et données arbitraires via le pattern get-or-compute de l'API bas niveau) vous permet de mettre en cache à exactement la bonne granularité pour chaque situation, et ses backends enfichables (en particulier Redis pour un cache partagé sur plusieurs serveurs — important car les caches en mémoire par processus ne sont pas partagés lors de la mise à l'échelle horizontale) conviennent à différents besoins de déploiement.
Savoir comment configurer la mise en cache, choisir le niveau approprié et sélectionner le bon backend pour le déploiement est une connaissance pratique et fréquemment nécessaire.
Tout aussi important est de comprendre la difficulté centrale de la mise en cache — l'invalidation (le problème fameux de l'effacement ou du rafraîchissement des données mises en cache quand les données sous-jacentes changent, via TTLs, suppression explicite lors des écritures, ou versioning des clés, pour éviter de servir des données obsolètes) — car bien faire cela est l'échec classique de la mise en cache qui montre aux utilisateurs des informations outdated.
Aussi savoir quoi mettre en cache (données coûteuses et rarement changeantes) plutôt que quoi ne pas faire (données très dynamiques ou sensibles) est clé pour utiliser la mise en cache efficacement.
Parce que la mise en cache livre des gains de performance majeurs mais nécessite une invalidation soignée, maîtriser le framework de mise en cache de Django — les niveaux, les backends, et en particulier les stratégies d'invalidation — est une connaissance importante pour construire des applications performantes et scalables et une marque des développeurs qui peuvent rendre les apps Django rapides sous charge réelle.