Utilisation des session, taille maximale possible

Le
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Olivier Miakinen
Le #66854

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
Le #66853
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
Le #66852

Heu, Olivier... tu fatigues ?


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

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
Le #66851
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
Le #66850
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
Le #67492
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
Le #67489
On 13 jan, 15:44, Marc

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


Marc
Le #67487
stefen76 wrote:

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
Le #67486
On 14 jan, 15:09, Marc
stefen76 wrote:
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.


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


Mickael Wolff
Le #67170
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
qui est meilleurs au niveau de la sécurité, et peut-être plus performant.


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 ?

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Publicité
Poster une réponse
Anonyme