Point 7.1 de la FAQ

Bonjour,

Cette méthode, la seule possible sous PHP3, reste la plus souple et la plus
fiable en ce qui concerne la capacité à maintenir le code.

Pourquoi est-ce plus souple/fiable que le mécanisme d'origine (fichiers
dans /tmp ?)

Justement, le mécanisme d'origine, c'est celui de php3 : <boche de
cuisine> demmerden sie zich elein</boche de cuisine>

Tout, absolument tout ce que font les sessions natives PHP4 on en avait
déjà besoin en PHP3. On sait faire. De même qu'on a pas attendu PHP5
pour faire du SOAP, on n'a pas attendu PHP4 pour faire des sessions.

L'avantage énorme des sessions natives PHP4, c'est que tu peux les
stocker en RAM => gain de perfs.

Ce qui est une souplesse se transformant souvent en catastrophe de style
"fourre-tout range merde" c'est que tu peux stocker n'importe quoi
dedans ou presque, donc avantage et inconvénient de l'effet de cache.

En revanche, voici une liste (non exhaustive) des problèmes liés aux
sessions natives PHP4 et/ou des choses que tu ne peux pas faire avec.

- dès que tu as deux machines frontales en load balancing, c'est fini,
sauf à avoir un load balancer intelligent qui te garantit que les
requêtes HTTP ayant l'air de venir d'une même machine arriveront
toujours sur le même frontal. Toute infrastructure un minimum sérieuse
interdira les montages à la con style NFS entre deux machines en DMZ.
Idem pour sqllite d'ailleurs.

- tu ne peux rien faire globalement des données de session. Si ton
cahier des charges te demande un écran d'administration avec "nombre de
connectés ayant eut une activité dans les xx dernière minutes", tu ne
peux pas faire. Avec des sessions en SGBDR, c'est une requête sql. Tu ne
pauex pas non plus jointurer directement des informations de session
(exemple : identifiant de l'article de ton caddie) avec une autre table
du SGBDR (au hasard : la table des produits).

- elles sont en soit une faille de sécurité de type erreur de
conception, ou en tous cas, elles l'encouragent : on ne **doit pas**
mettre de données sensibles en DMZ. Ca fait partie intégrante de la
définition du besoin d'une DMZ. Le SGBD n'est pas en DMZ.

- elles maintiennent une certaine confusion : cookies or not cookies,
vérification inutile (fausse sécurité) du referer, par exemple.

- je ne te garantis pas que tu maîtrises la fin de la session, et le
cahier des charges peut t'imposer de déclencher une action spécifique en
cas de détection d'un time out. Voir
http://fr2.php.net/manual/en/function.session-set-save-handler.php et
faire un test (le pointeur de fonction est-il bien appelé en cas de
time-out ou seulement en cas d'appel explicite à session_destroy)

A mon sens, les sessions natives ne sont pas adaptés à des systèmes
"scalable" : c'est super en RAM sur un frontal unique, mais à part ça,
ça tient pas la route ou c'est assez contraignant en pré-requis
externes. Maintenant comme d'habitude (je vais finir par la colelr en
signature, depuis le temps que je le dis...) : "à chaque besoin la
solution technique qui lui est la plus adaptée". Une chose est sûre : ça
prend deux fonctions et trois requêtes SQL de s'en passer. Allez, trois
fonctions pour implémenter le bouton "me délogguer" que personne
n'utilise de toutes façons.

Donc : avoir son propre gestionnaire = plus souple, c'est clair.

Clair aussi pour la maintenance du code dans les années qui viennent de
passer, y'a qu'à voir le merdier que c'est sur
http://fr2.php.net/manual/en/ref.session.php entre la 4.2, la 4.3, la
4.2.3, le paramètre "session.bug_compat_42", avec ses 4 WARNING et
autant de "CAUTION".

On peut espérer que ça va un peu se calmer et que cette remarque sur la
maintenance du code va devenir caduque. M'enfin moi quand j'ai migré mes
clients de PHP3 à PHP4 et bientôt (du calme, on se presse pas) à PHP5,
j'ai eu et je n'aurai *pas un seul caractère* à changer dans mon code.

En revanche, on va maintenant pouvoir supprimer "plus fiable", mais
quand cet article de FAQ a été rédigé (il y a plus de 3 ou 4 ans), les
sessions natives nécessitaient encore quelques corrections^W
améliorations de bugs^W problèmes résiduels.

a++;
JG

L'avantage énorme des sessions natives PHP4, c'est que tu peux les
stocker en RAM => gain de perfs.

Puisqu'on parle des sessions elles me posent des problèmes de temps de
réponse sur un site a très forte fréquentation (+/- 2000 hit/seconde)

Mes sessions sont actuellement stockées dans une table MySQL sur un
backend (il y a en fait 3 apaches en front dans la DMZ), mais ca devient
trop lent pour ce que j'en fait (des stats essentiellement).

J'ai tenté sans succès d'utiliser des tables HEAP de MySQL (avantage du
stockage en RAM et pas de code a retoucher sur le gestionnaire de
session) car les champs sont limités à 255 caractère (MySQL 4.1)

Donc je cherche une solution de gestion des sessions qui soit capable de
tenir le choc (j'ai une variable de session modifiée sur 30% des hits
environ).
Je n'ai pas trouvé comment, par exemple, stocker ça en RAM autrement que
via la création d'un disque en RAM (ce qui est assez compliqué du reste
puisqu'il faut 1 que les serveurs en front accèdent tous aux mêmes
sessions et 2 gérer soit-même le garbage si on stocke les fichiers de
sessions dans des dossiers découpés, et pas question de mettre plus de
100000 fichiers de session dans un même dossier)

NB: tous les hotes sont Unix-like

Bref, si vous avez des idées ou des liens a cliquer....

--

http://SurveilleTonSite.sd2i.org
Alerte gratuite par mail en cas de problème sur votre site.

L'avantage énorme des sessions natives PHP4, c'est que tu peux les
stocker en RAM => gain de perfs.

c'est dans le php.ini ca?
ca gagne vraiment beaucoup?
c'est quel processus qui recoit les données des sessions?
J'y connais pas grand chose, mais j'imagine que ces données sont tout de
meme reliées a un process unix!

Etienne

Re,

Puisqu'on parle des sessions elles me posent des problèmes de temps de
réponse sur un site a très forte fréquentation (+/- 2000 hit/seconde)

Ca commence à faire pas mal, d'où les 3 frontaux.

Mes sessions sont actuellement stockées dans une table MySQL sur un
backend (il y a en fait 3 apaches en front dans la DMZ), mais ca devient
trop lent pour ce que j'en fait (des stats essentiellement).

Combien de requêtes SQL /seconde ou minute ça fait en pointe, à partir
des hits http ? Quelels sont les ressoruces de la machine SGBDR qui sont
utilisées, peut-on les augmenter ?

Avant de chercher plus loin, tu parles de stats, peut-on vérifier l'algo
utilisé ?

Je n'ai pas trouvé comment, par exemple, stocker ça en RAM autrement que
via la création d'un disque en RAM (ce qui est assez compliqué du reste
puisqu'il faut 1 que les serveurs en front accèdent tous aux mêmes
sessions et 2 gérer soit-même le garbage si on stocke les fichiers de
sessions dans des dossiers découpés, et pas question de mettre plus de
100000 fichiers de session dans un même dossier)

Raison pour laquelle il n'est pas évident de faire le stockage sur les
frontaux. Sauf si ton load balancer te garanti que la même session (ou
tout ce qui y ressemble) arrive toujours sur le même frontal. Il parait
qu'il y en a qui le font (je ne sais pas comment ni si c'est fiable, vu
que l'IP apparente peut changer, mais bon, on doit pouvoir trouver des
choses, cf http://faqfclphp.free.fr/ au 7.5).

Maintenant, la gestion du garbage des fichiers, ca doit pouvoir se
faire. find n'est pas assez précis pour jouer avec des minutes/heures,
mais son code source est disponible, il suffirait peut-être de le
modifier pour pouvoir trouver les fichiers dont le atime est inférieur à
SYSDATE-temps_session. Ou d'écrire l'équivalent en PHP. Le tout devant
être en cron.

Bref, si vous avez des idées ou des liens a cliquer....
Essayer de laisser le boulot en amont sur le load balancer si tu veux

stocker sur les frontaux, ou optimiser les accès aux sessions SGBDR. La
piste des heap est pas mal, dans la même série, vérifier la répartition
des données par rapport aux index sur les disques (les axes physiques),
vérifier que c'est pas le réseau qui fout sa merde (par exemple s'il y a
un tunnel ssh, utiliser UDP au lieu de TCP). Comme dans tout problème de
perfs, la première chose à faire est de savoir qu'est-ce qui prend du
temps. Tu t'apercevras peut-être que c'est le parsing des fichiers php
cas dans lequel direction un encodeur, etc...

Si tu as plus d'infos chiffrées précises, on peut en discuter (ici ou en
privé).
a++;
JG

Bonjour,

L'avantage énorme des sessions natives PHP4, c'est que tu peux les
stocker en RAM => gain de perfs.

c'est dans le php.ini ca?
http://fr3.php.net/session

paragraphe Requirements

ca gagne vraiment beaucoup?
Ca risque pas de perdre. Mais selon le manuel, les locks sont pas gérés

correctement donc il faut du tempfs donc on va pas gagner grand chose si
effectivement il y des problèmes de locks (à prouver).

c'est quel processus qui recoit les données des sessions?
A priori aucun en particulier, shared mem.

J'y connais pas grand chose, mais j'imagine que ces données sont tout de
meme reliées a un process unix!
Autant que de process http ayant besoin d'y accéder.

a++;
JG