Utilisation des session, taille maximale possible

[stefen76]

Bonjour,

Dans un développement j'utilise les sessions, je stocke des données
sous forme de tableau, mais je me pose la question sur la quantité de
données que l'on peut mettre en session sans risque de perte ou de
surcharge du serveur.

Auriez-vous des infos à ce sujet ?

Merci à tous pour les réponse et bonne année.

Stéfen

[Olivier Miakinen]

Post by stefen76
Dans un développement j'utilise les sessions, je stocke des données
sous forme de tableau, mais je me pose la question sur la quantité de
données que l'on peut mettre en session sans risque de perte ou de
surcharge du serveur.

Surcharge du *serveur* ? J'ai l'impression que le problème risque plutôt
d'être dans le navigateur ou dans les tuyaux si tu transmets toutes ces
données de session à chaque requête/réponse.

Il me semble que la façon habituelle de procéder consiste à générer un
identifiant unique de quelques octets, et de mettre toutes des données
dans une base de données, plus précisément dans une table indexée par
l'id unique. Bien entendu, seul l'id sera transmis dans la session.

[Bruno Desthuilliers]

Post by Olivier Miakinen

Post by stefen76
Dans un développement j'utilise les sessions, je stocke des données
sous forme de tableau, mais je me pose la question sur la quantité de
données que l'on peut mettre en session sans risque de perte ou de
surcharge du serveur.

Surcharge du *serveur* ? J'ai l'impression que le problème risque plutôt
d'être dans le navigateur ou dans les tuyaux si tu transmets toutes ces
données de session à chaque requête/réponse.

Heu, Olivier... tu fatigues ?

En PHP, les sessions fonctionnent avec un identifiant (PHPSESSID) soit
stocké dans un cookie (par defaut), soit ajouté (par PHP) dans l'url
(selon ta config PHP), et un stockage des données sur le serveur (par
défaut et si ma mémoire est bonne, un tableau sérialisé dans un fichier
texte).

<OP>
Si tu a vraiment *beaucoup* d'infos à stocker et que tu utilises déjà
une base SQL, tu peux avoir intérêt à stocker une partie de ton bordel
dans la base. Surtout en fait pour éviter de bouffer trop de RAM, parce
que du point de vue I/O, tu ne gagnes pas forcément au change.
</OP>

[Olivier Miakinen]

Post by Bruno Desthuilliers
Heu, Olivier... tu fatigues ?

Il me semble surtout que j'ai encore plein de choses à apprendre.

Post by Bruno Desthuilliers
En PHP, les sessions fonctionnent avec un identifiant (PHPSESSID) soit
stocké dans un cookie (par defaut), soit ajouté (par PHP) dans l'url
(selon ta config PHP), et un stockage des données sur le serveur (par
défaut et si ma mémoire est bonne, un tableau sérialisé dans un fichier
texte).

J'ignorais. Et du coup, j'ai cru que Stefen avait l'intention de
transmettre toutes ses données de session au navigateur. Merci pour
ta réponse.

[stefen76]

Merci pour les réponses, je stocke déja pas mal d'infos dans ma base,
mais je me demandais si je stocke plus d'infos en session peut-être
que je'améliorai mes performances...
Stéfen

[Bruno Desthuilliers]

Post by stefen76
Merci pour les réponses, je stocke déja pas mal d'infos dans ma base,
mais je me demandais si je stocke plus d'infos en session peut-être
que je'améliorai mes performances...

A tu réellement des problèmes de perfs ? Si oui, avant toute autre
chose, installe toi un profileur et regarde où ça coince *vraiment*.
Toute autre approche est une pure perte de temps et d'énergie.

[Marc]

Post by stefen76
Bonjour,
Dans un développement j'utilise les sessions, je stocke des données
sous forme de tableau, mais je me pose la question sur la quantité de
données que l'on peut mettre en session sans risque de perte ou de
surcharge du serveur.
Auriez-vous des infos à ce sujet ?

par défaut, les données des sessions sont enregistrées dans des fichiers
temporaires. Ces données sont sérialisées.

Si le nombre de sessions simultanées est très importantes, il va y avoir
un soucis d'acces au répertoire. Unix n'aime pas bcp les répertoires
contenant enormément d'entrées. Dans ce cas, préférer une base de
données, ou encore réaliser sa propre fonction de gestion des sessions.

J'ai été assez bluffée par la rapidité de la sérialisation sur les
dernières versions de php. J'avais le souvenir d'une opération plutôt
lente en php4.

Si le tableau est très grand, on peu simuler la fonction tableau avec
des suites d'octets et les fonction pack / unpack. Mais c'est rentable
uniquement avec des tableaux très grands (> 10.000).

[stefen76]

Post by Marc

Post by stefen76
Bonjour,
Dans un développement j'utilise les sessions, je stocke des données
sous forme de tableau, mais je me pose la question sur la quantité de
données que l'on peut mettre en session sans risque de perte ou de
surcharge du serveur.
Auriez-vous des infos à ce sujet ?

par défaut, les données des sessions sont enregistrées dans des fichiers
temporaires. Ces données sont sérialisées.
Si le nombre de sessions simultanées est très importantes, il va y avoir
un soucis d'acces au répertoire. Unix n'aime pas bcp les répertoires
contenant enormément d'entrées. Dans ce cas, préférer une base de
données, ou encore réaliser sa propre fonction de gestion des sessions.
J'ai été assez bluffée par la rapidité de la sérialisation sur les
dernières versions de php. J'avais le souvenir d'une opération plutôt
lente en php4.
Si le tableau est très grand, on peu simuler la fonction tableau avec
des suites d'octets et les fonction pack / unpack. Mais c'est rentable
uniquement avec des tableaux très grands (> 10.000).

Merci pour toutes ses infos, mon tableau ne comporte pas 10000
entrées. Tout au plus il devrait y avoir une centaine d'entrée dans
mon tableau.
Stéfen

[Mickael Wolff]

Post by Marc
par défaut, les données des sessions sont enregistrées dans des fichiers
temporaires. Ces données sont sérialisées.

Et il est alors intéressant de préciser que les données de sessions
peuvent être conservées dans une base de données
<http://fr2.php.net/manual/fr/function.session-set-save-handler.php>. Ce
qui est meilleurs au niveau de la sécurité, et peut-être plus performant.

Post by Marc
Si le nombre de sessions simultanées est très importantes, il va y avoir
un soucis d'acces au répertoire. Unix n'aime pas bcp les répertoires
contenant enormément d'entrées. Dans ce cas, préférer une base de
données, ou encore réaliser sa propre fonction de gestion des sessions.

Vous devez confondre avec Microsoft Windows ;) Blague (et troll) à
part, quelle serait la raison d'une telle limitation ? Les OS classés
avec plus ou moins de pertinence sous le label Unix ont tous des
ordonnanceurs d'accès au disques différents, des mécanismes de cache
différents, un nombre assez incroyable de systèmes de fichiers. Sur
quelles fondations pouvez-vous affirmer un désamour de ces systèmes pour
les répertoire garnis ?

[Bruno Desthuilliers]

Marc a écrit :
(snip)

Post by Marc
Si le nombre de sessions simultanées est très importantes, il va y avoir
un soucis d'acces au répertoire.

Ah ???

Post by Marc
Unix n'aime pas bcp les répertoires
contenant enormément d'entrées.

<hs>
Ca c'est du grand n'import quoi, où je ne m'y connais pas...

1. "Unix" n'est pas "un" OS, mais un terme générique pour une famille d'OS

2. Il existe pour cette famille d'OS un bon nombre de systèmes de
fichiers différents, certains spécifique à un unix (ou unix-like)
spécifique, d'autres disponibles sur plusieurs unices.

3. Parmi ces systèmes de fichiers, certains sont plus ou moins orientés
pour des utilisations spécifiques, comme par exemple "grands fichiers"
(utiles pour des serveurs de base de données ou de contenus multimédias)
ou au contraire, justement, "pleins de petits fichiers", et certains
sont tout à fait génériques (et d'une manière générales fonctionnent
suffisament bien pour gérer les fichiers sessions d'un serveur web même
mutualisé).

</hs>

[Marc]

Post by stefen76
Dans un développement j'utilise les sessions, je stocke des données
sous forme de tableau, mais je me pose la question sur la quantité de
données que l'on peut mettre en session sans risque de perte ou de
surcharge du serveur.

encore une précision, les données en session n'ont aucune garantie de
survie. Si l'utilisateur effectue des manips et qu'il traine un
peu, il risque de laisser des données en session. Si le serveur
(Apache a prioris) est relancé, il y a de forte chances :
- que les anciens fichiers de sessions soient effacées,
- que l'utilisateur doive se reloger (sauf si identifiant gardé en cookie),
- qu'il lui soit affecté un nouveau ID de session,
-> et donc un nouveau contexte d'execution avec de nouvelles données
fraiches.

Pour bien comprendre, il faut savoir que les données de sessions
sont généralement sauvegardée dans des fichiers temporaires.

[stefen76]

Post by Marc

Post by stefen76
Dans un développement j'utilise les sessions, je stocke des données
sous forme de tableau, mais je me pose la question sur la quantité de
données que l'on peut mettre en session sans risque de perte ou de
surcharge du serveur.

encore une précision, les données en session n'ont aucune garantie de
survie. Si l'utilisateur effectue des manips et qu'il traine un
peu, il risque de laisser des données en session. Si le serveur
- que les anciens fichiers de sessions soient effacées,
- que l'utilisateur doive se reloger (sauf si identifiant gardé en cookie),
- qu'il lui soit affecté un nouveau ID de session,
-> et donc un nouveau contexte d'execution avec de nouvelles données
fraiches.
Pour bien comprendre, il faut savoir que les données de sessions
sont généralement sauvegardée dans des fichiers temporaires.

Oui cela ne me pose pas de problème, car je test si la session existe
ou pas. Sinon je remonte mes données dans la session.
Stéfen