Development #41026
install de base : utiliser un cache cohérent
0%
Description
Il faudrait configurer haproxy en proxy TCP vers les deux memcaches des deux noeuds, en priorité toujours sur le premier, parce que des fois des outils s'attendent à un cache cohérent (django-select2 par exemple).
Réfléchir à utiliser par défaut un backend de cache qui soit cohérent.
Demandes liées
Historique
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
- Lié à Bug #41017: select2 vs plusieurs serveurs derrière une IP ajouté
Mis à jour par Frédéric Péters il y a environ 4 ans
Je n'ai pas vu le problème sur le SaaS, le navigateur résoud une IP et semble s'y tenir.
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
Frédéric Péters a écrit :
Je n'ai pas vu le problème sur le SaaS, le navigateur résoud une IP et semble s'y tenir.
Oui mais le haproxy peut décider de balancer ça sur l'autre noeud non ? S'il a reçu une 500 dernièrement par exemple.
Mis à jour par Thomas Noël il y a environ 4 ans
Le problème se pose surtout sur des haproxy qu'on ne gère pas (toulouse et toodego) et donc on ne pourra pas faire grand chose.
Quid d'utiliser django.core.cache.backends.db.DatabaseCache (cache en base de données) ?
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
Thomas Noël a écrit :
Le problème se pose surtout sur des haproxy qu'on ne gère pas (toulouse et toodego) et donc on ne pourra pas faire grand chose.
Quid d'utiliser django.core.cache.backends.db.DatabaseCache (cache en base de données) ?
Oui, sur une instance peu utilisée (toodego/toulouse) ça doit passer, mais à toodego on a déjà redis en fait, c'est juste pas configuré coté GNM, mais il est disponible sur 10.128.3.70:6379 en recette et 10.128.2.250:6379 en prod.
Y a juste à mettre :
## Redis for cache and sessions
CACHES = {
"default": {
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "redis://redis.gl:6379/1",
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
},
"KEY_PREFIX": "cut_0_",
}
}
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
SESSION_CACHE_ALIAS = "default"
SESSION_COOKIE_AGE = 3600
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
- Projet changé de Admin système à Publik
- Sujet changé de rendre memcache cohérent à install de base : utiliser un cache cohérent
- Club mis à Non
Je déplace le ticket sur Publik parce que ça sort du cadre de notre SaaS en fait. Je pense que la proposition de Thomas est la bonne, dans publik-devinst et nos installs par défaut on devrait utiliser le cache en base (et le backend de session en base classique aussi, ça sert à rien de mettre la session deux fois en base); passer à memcache ou autre serait une optimisation à gérer manuellement, avec settings.d ce n'est maintenant pas trop dur.
Mis à jour par Frédéric Péters il y a environ 4 ans
À part le bout django-select2, il y a d'autres endroits qui posent problème ? (parce que je me dis que le bout select2 il doit pouvoir se corriger)
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
Frédéric Péters a écrit :
À part le bout django-select2, il y a d'autres endroits qui posent problème ? (parce que je me dis que le bout select2 il doit pouvoir se corriger)
Comment ?
Mis à jour par Frédéric Péters il y a environ 4 ans
Ma question étant surtout l'existence d'autres endroits concernés. Sur le comment, je n'ai pas regardé en détail mais à première vue il n'y a aucune construction particulière autour des widgets, ils sont statiques dans le queryset concerné, plutôt qu'une clé de cache une clé textuelle contenant juste le nom du widget concerné pourrait faire l'affaire. Alternativement faire sans django-select2 qui n'emmerde pas pour la première fois.
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
- Statut changé de Nouveau à Rejeté
Ça reviendra.