je travaille actuellement sur un projet dont je m'occuppe du
développement (PHP / Mysql / Apache). Par contre, nous n'hébergeons
pas le site.
Le client pour lequel nous travaillons, veut augmenter la charge de son
serveur. Ainsi, il veut passer son serveur en load balancing.
Cependant, l'application a besoin de variables de session pour par
exemple la gestion des différentes langues du site.
L'hébergeur nous demande de supprimer ces variables de sessions pour
que puissent fonctionner le site. Il nous dit que le load balancing ne
permet pas de gérer les sessions.
J'aurais diverses questions :
1. Peut-t-on faire fonctionner un site en load balancing tout en
conservant l'utilisation des sessions ?
2. Si non, comment gérer par un autre moyen les choix des utilisateurs
?
3. Si oui, quelle est la configuration à apporter ?
4. Quelles sont les principales questions à poser à l'hébergeur pour
avoir des précisions sur les techniques utilisées ?
L'hébergeur nous demande de supprimer ces variables de sessions pour que puissent fonctionner le site. Il nous dit que le load balancing ne permet pas de gérer les sessions.
J'aurais diverses questions :
1. Peut-t-on faire fonctionner un site en load balancing tout en conservant l'utilisation des sessions ?
Oui, si 1) les sessions sont gérées de telle façon qu'elles soient accessibles depuis tous les serveurs web, ie sur un disque partagé ou, plus probablement, dans une base de données OU 2) l'équipement qui fait le load balancing comprend les sessions (ie regarde le bon cookie, etc...) et oriente vers le bon serveur selon la session, auquel cas il n'est plus nécessaire de partager les sessions entre les différents serveurs. Une mise en oeuvre naïve mais simple consiste d'ailleurs dès le départ à faire une redirection spécifique vers un des serveurs (s'ils sont accessibles directement) et se débrouiller pour que tous les liens repointent sur le même.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
L'hébergeur nous demande de supprimer ces variables de sessions pour
que puissent fonctionner le site. Il nous dit que le load balancing ne
permet pas de gérer les sessions.
J'aurais diverses questions :
1. Peut-t-on faire fonctionner un site en load balancing tout en
conservant l'utilisation des sessions ?
Oui, si
1) les sessions sont gérées de telle façon qu'elles soient accessibles
depuis tous les serveurs web, ie sur un disque partagé ou, plus
probablement, dans une base de données
OU
2) l'équipement qui fait le load balancing comprend les sessions (ie
regarde le bon cookie, etc...) et oriente vers le bon serveur selon la
session, auquel cas il n'est plus nécessaire de partager les sessions
entre les différents serveurs.
Une mise en oeuvre naïve mais simple consiste d'ailleurs dès le départ
à faire une redirection spécifique vers un des serveurs (s'ils sont
accessibles directement) et se débrouiller pour que tous les liens
repointent sur le même.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
L'hébergeur nous demande de supprimer ces variables de sessions pour que puissent fonctionner le site. Il nous dit que le load balancing ne permet pas de gérer les sessions.
J'aurais diverses questions :
1. Peut-t-on faire fonctionner un site en load balancing tout en conservant l'utilisation des sessions ?
Oui, si 1) les sessions sont gérées de telle façon qu'elles soient accessibles depuis tous les serveurs web, ie sur un disque partagé ou, plus probablement, dans une base de données OU 2) l'équipement qui fait le load balancing comprend les sessions (ie regarde le bon cookie, etc...) et oriente vers le bon serveur selon la session, auquel cas il n'est plus nécessaire de partager les sessions entre les différents serveurs. Une mise en oeuvre naïve mais simple consiste d'ailleurs dès le départ à faire une redirection spécifique vers un des serveurs (s'ils sont accessibles directement) et se débrouiller pour que tous les liens repointent sur le même.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Marc Quinton
Dodou wrote:
1. Peut-t-on faire fonctionner un site en load balancing tout en conservant l'utilisation des sessions ?
* par defaut les variables de sessions sont enregistrées localement sur un repertoire temporaire. Ce repertoire ne peux donc pas etre partagé puisque local par plusieurs machines. D'autre part si on place l'espace de stockage sur un espace réseau, il y aura des collisions.
* cependant il est possible d'enregistrer pour votre application un gestionnnaire de session qui ira enregistrer dans une base de données ce qui résidait avant dans un fichier.
2. Si non, comment gérer par un autre moyen les choix des utilisateurs
* utiliser les services offerts par les bases de données, * placer des informations dans un cookie.
je pense avoir fait le tour.
Dodou wrote:
1. Peut-t-on faire fonctionner un site en load balancing tout en
conservant l'utilisation des sessions ?
* par defaut les variables de sessions sont enregistrées localement
sur un repertoire temporaire. Ce repertoire ne peux donc pas
etre partagé puisque local par plusieurs machines. D'autre part
si on place l'espace de stockage sur un espace réseau, il y aura
des collisions.
* cependant il est possible d'enregistrer pour votre application
un gestionnnaire de session qui ira enregistrer dans une base
de données ce qui résidait avant dans un fichier.
2. Si non, comment gérer par un autre moyen les choix des utilisateurs
* utiliser les services offerts par les bases de données,
* placer des informations dans un cookie.
1. Peut-t-on faire fonctionner un site en load balancing tout en conservant l'utilisation des sessions ?
* par defaut les variables de sessions sont enregistrées localement sur un repertoire temporaire. Ce repertoire ne peux donc pas etre partagé puisque local par plusieurs machines. D'autre part si on place l'espace de stockage sur un espace réseau, il y aura des collisions.
* cependant il est possible d'enregistrer pour votre application un gestionnnaire de session qui ira enregistrer dans une base de données ce qui résidait avant dans un fichier.
2. Si non, comment gérer par un autre moyen les choix des utilisateurs
* utiliser les services offerts par les bases de données, * placer des informations dans un cookie.
je pense avoir fait le tour.
Etienne SOBOLE
1. Peut-t-on faire fonctionner un site en load balancing tout en conservant l'utilisation des sessions ?
Oui. la plupart des load balancer sont capables de conserver l'association IP-serveur c'est à dire qu'un utilisateur ne changera pas de serveur durant sa session. Si le load balancer de ton client ne gère pas ca, ca veut dire que c'est un vieux truc qui va bientot rendre l'ame ;)
2. Si non, comment gérer par un autre moyen les choix des utilisateurs 3. Si oui, quelle est la configuration à apporter ?
Si vraiement tu n'as pas de session, tu peux faire diffenrent trucs! 1 - (facile) Envoyer la session dans chaque url. il suffit de configurer le php.ini Inconveniant de la methode: - faut pas trop fabriquer ou appeler des url en javascript - lorsque l'utilisateur bookmark la page, ben il bookmark la session avec, donc la fois d'apres son lien ne marchera probablement pas 2 - (plus compliqué) Utiliser les sous domaine comme identifiant de session. Inconveniant de la methode: - Necessite d'avoir la main sur le serveur DNS 3 - (logique) Monter le repertoire ou PHP sauve ses session sur une partition NFS commune (comme ca quelquesoit le serveur utilisé par le client le fichier de session sera le meme) Inconveniant de la methode: - J'ai jamais testé, mais j'imagine que cela doit avoir un coût en terme de temps CPU.
4. Quelles sont les principales questions à poser à l'hébergeur pour avoir des précisions sur les techniques utilisées ?
Ben simplement de savoir si son loadbalancer peut gérer les associations IP-Serveur.
PS : le loadbalancing c'est bien, mais si tu utilises une base de données, peut etre peux tu déjà te demander si la séparation Web - DB ne resoudrait pas une partie de ton probleme.
Bref. finalement, et pour la sciences, un montage NFS permettrait - de ne rien toucher a ton site, - de fonctionner avec n'importe quel nombre de serveur - de fonctionner meme avec un loadbalancer préhistorique - enrichir les connaissances des personnes de ce newsgroup en nous disant si ca marche ;)
Voila. Si tu optes pour cette solution, ben ecrit moi (en virant le -nospam de mon email) car ca m'interesse de savoir ce que ca donne.
Etienne
1. Peut-t-on faire fonctionner un site en load balancing tout en
conservant l'utilisation des sessions ?
Oui.
la plupart des load balancer sont capables de conserver l'association
IP-serveur
c'est à dire qu'un utilisateur ne changera pas de serveur durant sa session.
Si le load balancer de ton client ne gère pas ca, ca veut dire que c'est un
vieux truc qui va bientot rendre l'ame ;)
2. Si non, comment gérer par un autre moyen les choix des utilisateurs
3. Si oui, quelle est la configuration à apporter ?
Si vraiement tu n'as pas de session, tu peux faire diffenrent trucs!
1 - (facile) Envoyer la session dans chaque url. il suffit de configurer le
php.ini
Inconveniant de la methode:
- faut pas trop fabriquer ou appeler des url en javascript
- lorsque l'utilisateur bookmark la page, ben il bookmark la session
avec, donc la fois d'apres son lien ne marchera probablement pas
2 - (plus compliqué) Utiliser les sous domaine comme identifiant de session.
Inconveniant de la methode:
- Necessite d'avoir la main sur le serveur DNS
3 - (logique) Monter le repertoire ou PHP sauve ses session sur une
partition NFS commune (comme ca quelquesoit le serveur utilisé par le client
le fichier de session sera le meme)
Inconveniant de la methode:
- J'ai jamais testé, mais j'imagine que cela doit avoir un coût en terme
de temps CPU.
4. Quelles sont les principales questions à poser à l'hébergeur pour
avoir des précisions sur les techniques utilisées ?
Ben simplement de savoir si son loadbalancer peut gérer les associations
IP-Serveur.
PS : le loadbalancing c'est bien, mais si tu utilises une base de données,
peut etre peux tu déjà te demander si la séparation Web - DB ne resoudrait
pas une partie de ton probleme.
Bref.
finalement, et pour la sciences,
un montage NFS permettrait
- de ne rien toucher a ton site,
- de fonctionner avec n'importe quel nombre de serveur
- de fonctionner meme avec un loadbalancer préhistorique
- enrichir les connaissances des personnes de ce newsgroup en nous disant si
ca marche ;)
Voila.
Si tu optes pour cette solution, ben ecrit moi (en virant le -nospam de mon
email) car ca m'interesse de savoir ce que ca donne.
1. Peut-t-on faire fonctionner un site en load balancing tout en conservant l'utilisation des sessions ?
Oui. la plupart des load balancer sont capables de conserver l'association IP-serveur c'est à dire qu'un utilisateur ne changera pas de serveur durant sa session. Si le load balancer de ton client ne gère pas ca, ca veut dire que c'est un vieux truc qui va bientot rendre l'ame ;)
2. Si non, comment gérer par un autre moyen les choix des utilisateurs 3. Si oui, quelle est la configuration à apporter ?
Si vraiement tu n'as pas de session, tu peux faire diffenrent trucs! 1 - (facile) Envoyer la session dans chaque url. il suffit de configurer le php.ini Inconveniant de la methode: - faut pas trop fabriquer ou appeler des url en javascript - lorsque l'utilisateur bookmark la page, ben il bookmark la session avec, donc la fois d'apres son lien ne marchera probablement pas 2 - (plus compliqué) Utiliser les sous domaine comme identifiant de session. Inconveniant de la methode: - Necessite d'avoir la main sur le serveur DNS 3 - (logique) Monter le repertoire ou PHP sauve ses session sur une partition NFS commune (comme ca quelquesoit le serveur utilisé par le client le fichier de session sera le meme) Inconveniant de la methode: - J'ai jamais testé, mais j'imagine que cela doit avoir un coût en terme de temps CPU.
4. Quelles sont les principales questions à poser à l'hébergeur pour avoir des précisions sur les techniques utilisées ?
Ben simplement de savoir si son loadbalancer peut gérer les associations IP-Serveur.
PS : le loadbalancing c'est bien, mais si tu utilises une base de données, peut etre peux tu déjà te demander si la séparation Web - DB ne resoudrait pas une partie de ton probleme.
Bref. finalement, et pour la sciences, un montage NFS permettrait - de ne rien toucher a ton site, - de fonctionner avec n'importe quel nombre de serveur - de fonctionner meme avec un loadbalancer préhistorique - enrichir les connaissances des personnes de ce newsgroup en nous disant si ca marche ;)
Voila. Si tu optes pour cette solution, ben ecrit moi (en virant le -nospam de mon email) car ca m'interesse de savoir ce que ca donne.
Etienne
Patrick Mevzek
la plupart des load balancer sont capables de conserver l'association IP-serveur c'est à dire qu'un utilisateur ne changera pas de serveur durant sa session. Si le load balancer de ton client ne gère pas ca, ca veut dire que c'est un vieux truc qui va bientot rendre l'ame ;)
Ca a des avantages et des inconvénients. Parce que, en particulier: 1) ca n'assure pas statistiquement en permanence la meilleure répartition (on peut se retrouver à un moment avec tous les utilisateurs collés sur le même serveur)
2) ca empêche de prendre en compte la charge des machines (ou d'autres paramètres, comme le type de requête) pour aiguiller la demande, ce qui fait partie des fonctionnalités qu'on peut attendre d'un répartiteur de charge.
3) ca doit faire attention à gérer les pannes de machine pour re-aiguiller vers une autre (quite à perdre la session en cours)
Si vraiement tu n'as pas de session, tu peux faire diffenrent trucs! 1 - (facile) Envoyer la session dans chaque url. il suffit de configurer le php.ini Inconveniant de la methode: - faut pas trop fabriquer ou appeler des url en javascript - lorsque l'utilisateur bookmark la page, ben il bookmark la session avec, donc la fois d'apres son lien ne marchera probablement pas
Ben il suffit de faire une application intelligente qui, quand elle reçoit une requête avec une session expirée, redemande l'authentification, et après, de manière transparente redirige vers ce qui était demandé au début. Un peu plus de travail (mais si c'est fait correctement au début, c'est à peu près transparent pour le coeur de l'application), mais cela résout tous les problèmes de liens avec des mauvais numéros de session.
3 - (logique) Monter le repertoire ou PHP sauve ses session sur une partition NFS commune (comme ca quelquesoit le serveur utilisé par le client le fichier de session sera le meme) Inconveniant de la methode: - J'ai jamais testé, mais j'imagine que cela doit avoir un coût en terme de temps CPU.
Autre problème éventuel : les soucis de vérouillage. NFS n'a jamais été réputé pour gérer correctement le verrouillage en cas de charge.
finalement, et pour la sciences, un montage NFS permettrait - de ne rien toucher a ton site, - de fonctionner avec n'importe quel nombre de serveur - de fonctionner meme avec un loadbalancer préhistorique - enrichir les connaissances des personnes de ce newsgroup en nous disant si ca marche ;)
Ca doit marcher, mais personnellement, pour un site à traffic non nul, je prendrais plutôt une base de données (ou un truc style Memcached) pour gérer les données des sessions (afin d'avoir le problème du verrouillage clairement pris en compte) plutôt qu'un export NFS.
Tout ce qui précède n'a que très peu à voir spécifiquement avec PHP (si ce n'est le support intégré pour les sessions).
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
la plupart des load balancer sont capables de conserver l'association
IP-serveur
c'est à dire qu'un utilisateur ne changera pas de serveur durant sa session.
Si le load balancer de ton client ne gère pas ca, ca veut dire que c'est un
vieux truc qui va bientot rendre l'ame ;)
Ca a des avantages et des inconvénients.
Parce que, en particulier:
1) ca n'assure pas statistiquement en permanence la meilleure répartition
(on peut se retrouver à un moment avec tous les utilisateurs collés sur
le même serveur)
2) ca empêche de prendre en compte la charge des machines (ou
d'autres paramètres, comme le type de requête) pour aiguiller la
demande, ce qui fait partie des fonctionnalités qu'on peut attendre d'un
répartiteur de charge.
3) ca doit faire attention à gérer les pannes de machine pour
re-aiguiller vers une autre (quite à perdre la session en cours)
Si vraiement tu n'as pas de session, tu peux faire diffenrent trucs! 1 -
(facile) Envoyer la session dans chaque url. il suffit de configurer le
php.ini
Inconveniant de la methode:
- faut pas trop fabriquer ou appeler des url en javascript - lorsque
l'utilisateur bookmark la page, ben il bookmark la session
avec, donc la fois d'apres son lien ne marchera probablement pas
Ben il suffit de faire une application intelligente qui, quand elle
reçoit une requête avec une session expirée, redemande
l'authentification, et après, de manière transparente redirige vers ce
qui était demandé au début.
Un peu plus de travail (mais si c'est fait correctement au début, c'est
à peu près transparent pour le coeur de l'application), mais cela
résout tous les problèmes de liens avec des mauvais numéros de session.
3 - (logique) Monter le repertoire ou PHP sauve ses session sur une
partition NFS commune (comme ca quelquesoit le serveur utilisé par le
client le fichier de session sera le meme) Inconveniant de la methode:
- J'ai jamais testé, mais j'imagine que cela doit avoir un coût en
terme de temps CPU.
Autre problème éventuel : les soucis de vérouillage.
NFS n'a jamais été réputé pour gérer correctement le verrouillage en
cas de charge.
finalement, et pour la sciences,
un montage NFS permettrait
- de ne rien toucher a ton site,
- de fonctionner avec n'importe quel nombre de serveur - de fonctionner
meme avec un loadbalancer préhistorique - enrichir les connaissances
des personnes de ce newsgroup en nous disant si ca marche ;)
Ca doit marcher, mais personnellement, pour un site à traffic non nul, je
prendrais plutôt une base de données (ou un truc style Memcached) pour
gérer les données des sessions (afin d'avoir le problème du
verrouillage clairement pris en compte) plutôt qu'un export NFS.
Tout ce qui précède n'a que très peu à voir spécifiquement avec PHP
(si ce n'est le support intégré pour les sessions).
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
la plupart des load balancer sont capables de conserver l'association IP-serveur c'est à dire qu'un utilisateur ne changera pas de serveur durant sa session. Si le load balancer de ton client ne gère pas ca, ca veut dire que c'est un vieux truc qui va bientot rendre l'ame ;)
Ca a des avantages et des inconvénients. Parce que, en particulier: 1) ca n'assure pas statistiquement en permanence la meilleure répartition (on peut se retrouver à un moment avec tous les utilisateurs collés sur le même serveur)
2) ca empêche de prendre en compte la charge des machines (ou d'autres paramètres, comme le type de requête) pour aiguiller la demande, ce qui fait partie des fonctionnalités qu'on peut attendre d'un répartiteur de charge.
3) ca doit faire attention à gérer les pannes de machine pour re-aiguiller vers une autre (quite à perdre la session en cours)
Si vraiement tu n'as pas de session, tu peux faire diffenrent trucs! 1 - (facile) Envoyer la session dans chaque url. il suffit de configurer le php.ini Inconveniant de la methode: - faut pas trop fabriquer ou appeler des url en javascript - lorsque l'utilisateur bookmark la page, ben il bookmark la session avec, donc la fois d'apres son lien ne marchera probablement pas
Ben il suffit de faire une application intelligente qui, quand elle reçoit une requête avec une session expirée, redemande l'authentification, et après, de manière transparente redirige vers ce qui était demandé au début. Un peu plus de travail (mais si c'est fait correctement au début, c'est à peu près transparent pour le coeur de l'application), mais cela résout tous les problèmes de liens avec des mauvais numéros de session.
3 - (logique) Monter le repertoire ou PHP sauve ses session sur une partition NFS commune (comme ca quelquesoit le serveur utilisé par le client le fichier de session sera le meme) Inconveniant de la methode: - J'ai jamais testé, mais j'imagine que cela doit avoir un coût en terme de temps CPU.
Autre problème éventuel : les soucis de vérouillage. NFS n'a jamais été réputé pour gérer correctement le verrouillage en cas de charge.
finalement, et pour la sciences, un montage NFS permettrait - de ne rien toucher a ton site, - de fonctionner avec n'importe quel nombre de serveur - de fonctionner meme avec un loadbalancer préhistorique - enrichir les connaissances des personnes de ce newsgroup en nous disant si ca marche ;)
Ca doit marcher, mais personnellement, pour un site à traffic non nul, je prendrais plutôt une base de données (ou un truc style Memcached) pour gérer les données des sessions (afin d'avoir le problème du verrouillage clairement pris en compte) plutôt qu'un export NFS.
Tout ce qui précède n'a que très peu à voir spécifiquement avec PHP (si ce n'est le support intégré pour les sessions).
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Marc Quinton
Dodou wrote:
Cependant, l'application a besoin de variables de session pour par exemple la gestion des différentes langues du site.
encore un truc sympa : http://sharedance.pureftpd.org/
Etienne SOBOLE
* par defaut les variables de sessions sont enregistrées localement sur un repertoire temporaire. Ce repertoire ne peux donc pas etre partagé puisque local par plusieurs machines. D'autre part si on place l'espace de stockage sur un espace réseau, il y aura des collisions.
hum. je ne suis que tres partiellement (voir pas trop) d'accord avec toi et patrick !!! lors de la creation d'une session, le php génére un id sur 512bit (32 octets) et il s'assure qu'il n'existe pas de fichier portant ce nom dans le repertoire de session.
la seule collision possible (d'apres moi, mais je n'avance que des suppositions), c'est que deux serveurs decident de générer en meme temps le meme ID au DEMARRAGE de la session (bonjour la probabilité).
Etienne
* par defaut les variables de sessions sont enregistrées localement
sur un repertoire temporaire. Ce repertoire ne peux donc pas
etre partagé puisque local par plusieurs machines. D'autre part
si on place l'espace de stockage sur un espace réseau, il y aura
des collisions.
hum.
je ne suis que tres partiellement (voir pas trop) d'accord avec toi et
patrick !!!
lors de la creation d'une session, le php génére un id sur 512bit (32
octets)
et il s'assure qu'il n'existe pas de fichier portant ce nom dans le
repertoire de session.
la seule collision possible (d'apres moi, mais je n'avance que des
suppositions), c'est que deux serveurs decident de générer en meme temps le
meme ID au DEMARRAGE de la session (bonjour la probabilité).
* par defaut les variables de sessions sont enregistrées localement sur un repertoire temporaire. Ce repertoire ne peux donc pas etre partagé puisque local par plusieurs machines. D'autre part si on place l'espace de stockage sur un espace réseau, il y aura des collisions.
hum. je ne suis que tres partiellement (voir pas trop) d'accord avec toi et patrick !!! lors de la creation d'une session, le php génére un id sur 512bit (32 octets) et il s'assure qu'il n'existe pas de fichier portant ce nom dans le repertoire de session.
la seule collision possible (d'apres moi, mais je n'avance que des suppositions), c'est que deux serveurs decident de générer en meme temps le meme ID au DEMARRAGE de la session (bonjour la probabilité).
Etienne
Patrick Mevzek
je ne suis que tres partiellement (voir pas trop) d'accord avec toi et patrick !!! lors de la creation d'une session, le php génére un id sur 512bit (32 octets) et il s'assure qu'il n'existe pas de fichier portant ce nom dans le repertoire de session.
Pour ma part ce n'est pas le problème que j'évoquais. Si deux requêtes arrivent simultanément (ou dans un laps de temps très court), et qu'un processus est en train de lire les informations de session alors qu'un autre est en train de les écrire (dans le même fichier donc). Est-on assuré d'avoir un résultat cohérent ?
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
je ne suis que tres partiellement (voir pas trop) d'accord avec toi et
patrick !!!
lors de la creation d'une session, le php génére un id sur 512bit (32
octets)
et il s'assure qu'il n'existe pas de fichier portant ce nom dans le
repertoire de session.
Pour ma part ce n'est pas le problème que j'évoquais.
Si deux requêtes arrivent simultanément (ou dans un laps de temps très
court), et qu'un processus est en train de lire les informations de
session alors qu'un autre est en train de les écrire (dans le même
fichier donc). Est-on assuré d'avoir un résultat cohérent ?
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
je ne suis que tres partiellement (voir pas trop) d'accord avec toi et patrick !!! lors de la creation d'une session, le php génére un id sur 512bit (32 octets) et il s'assure qu'il n'existe pas de fichier portant ce nom dans le repertoire de session.
Pour ma part ce n'est pas le problème que j'évoquais. Si deux requêtes arrivent simultanément (ou dans un laps de temps très court), et qu'un processus est en train de lire les informations de session alors qu'un autre est en train de les écrire (dans le même fichier donc). Est-on assuré d'avoir un résultat cohérent ?
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Etienne SOBOLE
https://www.zend.com/whitepapers/platform/Zend_Platform_Session_Clustering.pdf Ah ben voila tout est ecrit la dedans :)
Etienne
https://www.zend.com/whitepapers/platform/Zend_Platform_Session_Clustering.pdf
Ah ben voila tout est ecrit la dedans :)
https://www.zend.com/whitepapers/platform/Zend_Platform_Session_Clustering.pdf Ah ben voila tout est ecrit la dedans :)
Etienne
Marc
Pour ma part ce n'est pas le problème que j'évoquais. Si deux requêtes arrivent simultanément (ou dans un laps de temps très court), et qu'un processus est en train de lire les informations de session alors qu'un autre est en train de les écrire (dans le même fichier donc). Est-on assuré d'avoir un résultat cohérent ?
normalement oui, parce que :
* j'ai vu des flock dans le code gerant les sessions dans des fichiers (contrairement a ce que je pensais, donc erreur de ma part), * parce que, un serveur Web apache est nativement concurentiel puisque multi-processus.
Pour ma part ce n'est pas le problème que j'évoquais.
Si deux requêtes arrivent simultanément (ou dans un laps de temps très
court), et qu'un processus est en train de lire les informations de
session alors qu'un autre est en train de les écrire (dans le même
fichier donc). Est-on assuré d'avoir un résultat cohérent ?
normalement oui, parce que :
* j'ai vu des flock dans le code gerant les sessions dans
des fichiers (contrairement a ce que je pensais, donc erreur
de ma part),
* parce que, un serveur Web apache est nativement concurentiel
puisque multi-processus.
Pour ma part ce n'est pas le problème que j'évoquais. Si deux requêtes arrivent simultanément (ou dans un laps de temps très court), et qu'un processus est en train de lire les informations de session alors qu'un autre est en train de les écrire (dans le même fichier donc). Est-on assuré d'avoir un résultat cohérent ?
normalement oui, parce que :
* j'ai vu des flock dans le code gerant les sessions dans des fichiers (contrairement a ce que je pensais, donc erreur de ma part), * parce que, un serveur Web apache est nativement concurentiel puisque multi-processus.
