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.
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.
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.
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
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>
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>
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
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.
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.
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
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
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
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
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.
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.
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
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).
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).
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
On 13 jan, 15:44, Marc wrote:
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
On 13 jan, 15:44, Marc <mq-fra...@gmail.com> wrote:
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
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
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 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.
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
On 14 jan, 15:09, Marc wrote:
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
On 14 jan, 15:09, Marc <mq.fra...@gmail.com> wrote:
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
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
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.
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 ?
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.
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 ?
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.
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 ?
