Tous les mécanismes qui nécessitent de se passer la session sur un serveur centralisé ont plusieurs problèmes
Le premier est la performance. Si on veut enregistrer les données sur disque à chaque requête, il va sans dire qu'il faut mettre le minimum de données en session, c'est pourtant rarement l'objectif des développeurs lorsqu'ils écrivent une application, ils utilisent plutot la session comme cache des données utilisateur.
Lorsque les données sont en plus enregistré dans une base de donnée, particulièrement MySQL qui verrouille souvent au niveau de la table. L'enregistrement de plusieurs Ko de données est catastrophique.
Le partage NFS est aussi souvent utilisé; mais le verrouillage des fichiers n'est alors généralement pas géré.
Le second problème est la redondance. Si le serveur de session tombe, parce qu'il est trop chargé, ou parce qu'il y a un problème matériel sur la machine; le service est complètement coupé. On souhaite souvent avoir un mécanisme de secours, même si les sessions sont perdues, les gens doivent pouvoir en ouvrir une nouvelle. Les mécanismes à serveur unique fonctionnent mal dans ce cas. Les serveurs SQL peuvent être souvent installés en clusters, mais dans ce cas, le temps de traitement des requêtes est également augmenté; ce qui augmente les risques d'écroulement sous la charge.
La technique que j'utilise est le proxy avec affinité de session. Cela permet de distribuer en amont, avec un logiciel ou un équipement dédié, le routage de toutes les requêtes d'un même client vers le même serveur. Ainsi la session peu rester locale à l'application.
# Performances, redondance
Posté par Sébastien Koechlin . En réponse au journal Centralisation des sessions PHP: mysql, mcache, sharedance, etc .... Évalué à 5.
Le premier est la performance. Si on veut enregistrer les données sur disque à chaque requête, il va sans dire qu'il faut mettre le minimum de données en session, c'est pourtant rarement l'objectif des développeurs lorsqu'ils écrivent une application, ils utilisent plutot la session comme cache des données utilisateur.
Lorsque les données sont en plus enregistré dans une base de donnée, particulièrement MySQL qui verrouille souvent au niveau de la table. L'enregistrement de plusieurs Ko de données est catastrophique.
Le partage NFS est aussi souvent utilisé; mais le verrouillage des fichiers n'est alors généralement pas géré.
Le second problème est la redondance. Si le serveur de session tombe, parce qu'il est trop chargé, ou parce qu'il y a un problème matériel sur la machine; le service est complètement coupé. On souhaite souvent avoir un mécanisme de secours, même si les sessions sont perdues, les gens doivent pouvoir en ouvrir une nouvelle. Les mécanismes à serveur unique fonctionnent mal dans ce cas. Les serveurs SQL peuvent être souvent installés en clusters, mais dans ce cas, le temps de traitement des requêtes est également augmenté; ce qui augmente les risques d'écroulement sous la charge.
La technique que j'utilise est le proxy avec affinité de session. Cela permet de distribuer en amont, avec un logiciel ou un équipement dédié, le routage de toutes les requêtes d'un même client vers le même serveur. Ainsi la session peu rester locale à l'application.
Un logiciel qui permet de faire cela est Pound http://www.apsis.ch/pound