Le jour où l'on ajoute un second serveur

Tant qu'Odoo tourne sur une seule machine, les sessions vivent sur son disque et personne ne s'en préoccupe. Le jour où l'on ajoute un serveur pour absorber la charge, le problème apparaît aussitôt : l'utilisateur qui arrive sur la seconde machine n'y est pas reconnu, et se retrouve déconnecté au fil de sa navigation.

Externaliser les sessions dans un stockage partagé résout cela une fois pour toutes. C'est le préalable à toute répartition de charge, et accessoirement ce qui permet de redémarrer un serveur sans éjecter tout le monde.

Fonctionnalités principales

• Sessions utilisateur externalisées (HA en option) pour le load-balancing.
• Cache de résultats (requêtes coûteuses, rendu QWeb) avec TTL.
• Locks distribués pour éviter les traitements concurrents.
• Rate limiting & anti-bouclement de jobs.
• Métriques basiques : clés, mémoire, hit ratio.

Données échangées (exemples)

• Clés de session, cookies signés, jetons CSRF.
• Fragments de rendu, réponses JSON, résultats d’ORM sérialisés.
• Verrous (SETNX) et compteurs.

Questions fréquentes

Est-ce que cela accélère Odoo ?

Indirectement. La mise en cache évite de recalculer ce qui est coûteux et stable, mais elle ne répare pas un traitement mal écrit : elle en masque le coût jusqu'au jour où le cache est vide. Le gain réel est ailleurs, dans la possibilité de répartir la charge sur plusieurs serveurs.

À quoi servent les verrous distribués ?

À empêcher que deux serveurs exécutent le même traitement au même moment. Sans eux, une tâche planifiée peut partir deux fois et produire deux fois ses effets — deux envois, deux écritures, deux commandes fournisseur.

Que se passe-t-il si le service tombe ?

Les sessions sont perdues et les utilisateurs doivent se reconnecter ; les données métier, elles, sont dans la base et ne bougent pas. C'est un choix d'architecture à assumer : ce stockage est rapide parce qu'il vit en mémoire.