Journal : Centralisation des sessions PHP: mysql, mcache, sharedance, etc ...
Posté par DjinnS (page perso, ) le 16 janvier 2007
Salut,
Imaginons une webfarm. Plusieurs serveurs Web distribuant le même contenu. Comment garder la même session d'un serveur à l'autre ? Car l'utlisateur "basculera" forcement d'un serveur à un autre.
PHP étant la technologie qui nous interesse ici (et souvent la plus utilisée pour délivrer du contenu dynamique sur le Web actuellement), a déja tout prévu: session_set_save_handler() [1].
Avec cette fonction il est possible de redefinir le comportement des sessions. C'est donc très pratique pour avoir sa petite gestion personnalisée.
La solution qui vient en premier à l'esprit (enfin c'était mon cas) est le stockage dans une base MySQL [2]. Ca semble être un moyen efficace et relativement simple à mettre en place. D'après le WP de chez MySQL c'est LA solution à tout nos problemes: performance, evolutivité, efficacité, coùt, sécurité, etc ... c'est presque la perfection absolue.
Je suis en accord avec un certains nombre de points: coùt, évolutivité (c'est un point tres important, car il faut penser à pouvoir peut être plus tard à faire une ferme de serveur de session), facilité de mise en place et d'utilisation. La sécurité est relativement simple, même si il semble possible de vérouiller quelques points avec les droits et ACM de MySQL. On nous tartine aussi un petit coup sur les procédures stockées de MySQL 5.0.
Mais au final, ca sent quand même la plaquette de vente. C'est le but, évidement. Même si le systeme reste alléchant.
Mais pourquoi exist-il alors d'autres solutions ?
Une d'elle est mcache [3]. Lui aussi nous promet un fonctionnement simple, une efficacité maximale et bien plus de souplesse que ne le permet le stockage simple dans une BDD. Il sait le faire si l'on le souhaite, en parrallèle pour évidement ne pas tout perde si la machine reboot ou etc ... On apprécira le fait qu'il gère avec efficacité les accès concurent, un point important du partage de sessions.
Mais la où personnellement ca pêche un peu c'est en terme d'évolutivité.
"5000 full session operations" en une seconde, c'est certe beaucoup mais je ne trouve pas ca "hallucinant". Qu'est ce qu'on fait au delas de ce chiffre ? Est-il possible de mettre plusieurs serveurs mcache (load balancing avec systeme de fichier distribué ?) en place ?
Je me suis aussi interessé à ShareDance [4], l'exellent. Les commentaires sont tous dans un sens: il est génial. En grand fan de pureftpd je regarde un peu la doc ... et je suis aussi séduit. Reste l'évolutivité, la monté en charge et donc l'ajout en parrallèle de serveur ShareDance ? J'imagine que pour les skyblogs il n'y a pas qu'un seul serveur qui gère les sessions ... et étant donné que le systeme est une simple session TCP je me vois bien faire du LB dessus avec un système de fichier distribué derrière.
En gros, je cherche quelques retour d'expérience sur ce sujet. Comment avez vous fait de votre coté ? BDD ? mcache ? ShareDance ? Ou peut être une autre solution ?
Si vous avez utilisé ShareDance, qu'en pensez vous ? Est-il possible de faire de la balance de charge ?
Avant de monter une plate forme de test, je souhaiterais juste savoir si je ne me trompe pas de chemin :)
* [1]: http://fr2.php.net/manual/fr/function.session-set-save-handl(...)
* [2]: http://www.mysql.fr/why-mysql/white-papers/mysql_wp_sessionm(...)
* [3]: http://www.mohawksoft.org/?q=node/8
* [4]: http://sharedance.pureftpd.org/project/sharedance
Imaginons une webfarm. Plusieurs serveurs Web distribuant le même contenu. Comment garder la même session d'un serveur à l'autre ? Car l'utlisateur "basculera" forcement d'un serveur à un autre.
PHP étant la technologie qui nous interesse ici (et souvent la plus utilisée pour délivrer du contenu dynamique sur le Web actuellement), a déja tout prévu: session_set_save_handler() [1].
Avec cette fonction il est possible de redefinir le comportement des sessions. C'est donc très pratique pour avoir sa petite gestion personnalisée.
La solution qui vient en premier à l'esprit (enfin c'était mon cas) est le stockage dans une base MySQL [2]. Ca semble être un moyen efficace et relativement simple à mettre en place. D'après le WP de chez MySQL c'est LA solution à tout nos problemes: performance, evolutivité, efficacité, coùt, sécurité, etc ... c'est presque la perfection absolue.
Je suis en accord avec un certains nombre de points: coùt, évolutivité (c'est un point tres important, car il faut penser à pouvoir peut être plus tard à faire une ferme de serveur de session), facilité de mise en place et d'utilisation. La sécurité est relativement simple, même si il semble possible de vérouiller quelques points avec les droits et ACM de MySQL. On nous tartine aussi un petit coup sur les procédures stockées de MySQL 5.0.
Mais au final, ca sent quand même la plaquette de vente. C'est le but, évidement. Même si le systeme reste alléchant.
Mais pourquoi exist-il alors d'autres solutions ?
Une d'elle est mcache [3]. Lui aussi nous promet un fonctionnement simple, une efficacité maximale et bien plus de souplesse que ne le permet le stockage simple dans une BDD. Il sait le faire si l'on le souhaite, en parrallèle pour évidement ne pas tout perde si la machine reboot ou etc ... On apprécira le fait qu'il gère avec efficacité les accès concurent, un point important du partage de sessions.
Mais la où personnellement ca pêche un peu c'est en terme d'évolutivité.
If your requirements are higher than about 4000~5000 full session operations a second, depending on your server hardware, mcache may not be for you.
"5000 full session operations" en une seconde, c'est certe beaucoup mais je ne trouve pas ca "hallucinant". Qu'est ce qu'on fait au delas de ce chiffre ? Est-il possible de mettre plusieurs serveurs mcache (load balancing avec systeme de fichier distribué ?) en place ?
Je me suis aussi interessé à ShareDance [4], l'exellent. Les commentaires sont tous dans un sens: il est génial. En grand fan de pureftpd je regarde un peu la doc ... et je suis aussi séduit. Reste l'évolutivité, la monté en charge et donc l'ajout en parrallèle de serveur ShareDance ? J'imagine que pour les skyblogs il n'y a pas qu'un seul serveur qui gère les sessions ... et étant donné que le systeme est une simple session TCP je me vois bien faire du LB dessus avec un système de fichier distribué derrière.
En gros, je cherche quelques retour d'expérience sur ce sujet. Comment avez vous fait de votre coté ? BDD ? mcache ? ShareDance ? Ou peut être une autre solution ?
Si vous avez utilisé ShareDance, qu'en pensez vous ? Est-il possible de faire de la balance de charge ?
Avant de monter une plate forme de test, je souhaiterais juste savoir si je ne me trompe pas de chemin :)
* [1]: http://fr2.php.net/manual/fr/function.session-set-save-handl(...)
* [2]: http://www.mysql.fr/why-mysql/white-papers/mysql_wp_sessionm(...)
* [3]: http://www.mohawksoft.org/?q=node/8
* [4]: http://sharedance.pureftpd.org/project/sharedance
> Lire le journal (19 commentaires, moyenne: 2).
Vous avez demandé le commentaire #795062.
Run by 
Cette page a été générée par Templeet en 0.0485s (dont 0.0056 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Synchronisation des sessions en multicast ?
En Java (je connais pas plus que ça), il y a javagroups qui permet à Tomcat par exemple d'échanger les informations de sessions avec les autres Tomcat du cluster en multicast. Les sessions restent en mémoire et peuvent être sérialisée en fichiers ou en base si on veut.
Mais le principe de sessions en mémoire synchronisée en multicast (de la network shared memory en fait) doit pouvoir être très performant non ?
[^]Re: Synchronisation des sessions en multicast ?
Le problème est qu'avec ton script php tu va avoir un tit soucis.
Ça va demander a ton serveur qui heberge apache+php d'avoir un système de stockage de session local (mis a jour via multicast et qui envoie ses changement en multicast)
Car ton script php n'est pas permanent mais lancé a chaque consulation.
En fait j'avais finis pas régler un soucis du même genre pour avoir des stats en cours de l'upload d'un fichier en php.
La seule solution trouvée était de la mémoire partagée créé par le script qui reçois l'upload avec une clef X
(c'était un module en C de php)
Et le script de stats lisait cette même mémoire partagée si elle existait.
Mon seul problème est que le nombre d'emplacement de mémoire partagée sur un système linux est largement inférieur au nombre de session possible.
Donc tu utilise un algorithme de réduction de plage et donc gare au collisions...
(sur un petit site avec 3 upload en parallèle tu t'en tape carrément, mais pour de la prod critique de site de vente ou autre c'est inacceptable)
site perso : http://rapsys.free.fr/
[^]Re: Synchronisation des sessions en multicast ?
Pour avoir des données disponibles en mémoire d'une requête à l'autre il y a l'extension APC qui est pas mal:
apc_set('var','data');
$data = apc_fetch('var');
Apparemment la version CVS permet aussi de récupérer la progression des fichiers en cours d'upload avec php5.2 :)
http://www.whenpenguinsattack.com/2006/12/12/how-to-create-a(...)
[^]Re: Synchronisation des sessions en multicast ?
Effectivement pas mal comme possibilité.
Mais mon script permet de ne pas avoir les limites de cet exemple.
- possibilité d'utiliser mon système en cgi
- pas besoin d'apc actif
- marche en v4 et v5
Mais bon ça demande un patch qui ajoute deux parties:
- un handler en sup dans la rfcXXXX.c qui gère la reception de fichier
- un module a part qui exporte 3 fonctions :
=> réducteur d'identifiant
=> status de l'upload dont l'id est X
Bon j'ai aussi deux trois param pour ce module, notamment un paramètre pour choisir le backend (file ou mmap)
En fait mon seul soucis était de faire marcher avec le packaging standard de la mandriva 2007.0, mais je m'y suis pris trop tard. :'(
(en fait j'ai eu surtout la flemme de nettoyer le code de débug et de corriger un bug stupide, mais comme ça marchais j'ai pas touché a ce qui marche)
site perso : http://rapsys.free.fr/