programmation objet et sessions : taille memoir e et optimisations ?
1 réponse
Gabriel
bonjour,
je suis en train de développer un framework pour une gestion automatisée
des formulaires, pages, menu dynamiques, validation des données etc...
J'ai choisi une orientation objet pour le projet et je me pose une
question :
Afin d'éviter de passer mon temps à ré-instancier des objets pendant la
durée de la visite du visiteur sur le site, je cree un objet et je le
stocke systématiquement en session.
Ainsi s'il en a re-besoin, c'est déjà là :).
Je sais que les sessions ne sont pas un dépotoir :), mais je sais aussi
que la création des objets est ce qui prend le plus de temps en
développement orienté objet.
D'un autre coté, php est suffisament rapide pour créer les objets à la
volée (du moins il me semble :) ).
Risque-je, pour un gros projet de heurter la limite de la taille mémoire
gérable par la session ?
Ne serait-ce pas mieux de les recréer en fonction du besoin ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John Gallet
Bonjour,
Afin d'éviter de passer mon temps à ré-instancier des objets pendant la durée de la visite du visiteur sur le site, je cree un objet et je le stocke systématiquement en session.
Donc : quand tu stockes l'objet dans le fichier de session il est sérialisé (ses propriétés). Puis quand la session est réactivée, l'objet est... réinstancié à partir des données désérialisées. Te dire si PHP désérialise toute la session et instancie toutes les variables qu'elle contient dès le début, ou seulement si tu tentes réellement d'accéder à $SESSION['toto'] dans le script courant, je ne sais pas.
Je sais que les sessions ne sont pas un dépotoir :), mais je sais aussi que la création des objets est ce qui prend le plus de temps en développement orienté objet.
Leur sérialisation et désérialisation sur disque, c'est encore pire :-) Donc si tu peux stocker tes sessions PHP en mémoire, ne te prive pas.
La vraie question est de savoir si les données (les propriétés de cet objet) ont une raison valide de transiter sur le réseau entre le client et le serveur. C'est là que tu vas perdre du temps, si tu fais des aller-retours inutiles. Le temps passé à instancier l'objet à partir des données, qu'elles viennent par http ou depuis le disque dur de la machine est négligeable devant le temps mis à les transférer sur une ligne RTC ou à les lire sur disque... Quand tu es dans une application de type daemon ou appli grahique, bref, un truc qu'on lance et qui tourne "un certain temps" avant de s'arrêter, il faut en effet faire attention à la rémanence des données en mémoire (structures ou objets, peu importe). Dans le cadre de web dynamique, ça reste du "mode cgi" car les requêtes http sont indépéndantes et sur un protocole non connecté : il n'y a pas de persistence des objets en mémoire entre les requêtes, il faut les sérialiser (sur disque ou en RAM).
Risque-je, pour un gros projet de heurter la limite de la taille mémoire gérable par la session ? Bonne question, mais tu peux toi même avoir une idée de la réponse : les
sessions php sont stockées dans des fichiers en standard, des bêtes fichiers plats. Fais un super objet "énorme" selon les critères de ton application, mets le en session, et regarde la taille du fichier résultant.
Ne serait-ce pas mieux de les recréer en fonction du besoin ? Ceci implique alors que les données nécessaires à les créer transitent
sur le réseau. Est-ce que l'utilisateur peut les modifier ? Si oui, alors il est de toutes façons inutile de les mettre en session. En revanche, si c'est seulement pour le plaisir de les faire transiter en HIDDEN, ça n'aucun intérêt non plus, autant les stocker côté serveur.
Quel sont vos avis sur la question ? A mon sens, tu ne te poses pas le problème dans le bon ordre. Analyse
d'abord le flux de tes données. Une session (quel que soit son mode de stockage, native php ou non) est faite pour deux besoins : 1) conserver une donnée côté serveur pour la comparer avec ce qui arrive la fois d'après (identifiant de session par exemple, jeton de sécurité etc...) 2) conserver des données pour éviter de les faire systématiquement transiter sur toutes les pages (et de refaire les traitements de validation associés) parce qu'elles sont définies à un niveau N de la navigation et qu'on en aura pas besoin avant le niveau N+x.
a++ JG
Bonjour,
Afin d'éviter de passer mon temps à ré-instancier des objets pendant la
durée de la visite du visiteur sur le site, je cree un objet et je le
stocke systématiquement en session.
Donc : quand tu stockes l'objet dans le fichier de session il est
sérialisé (ses propriétés). Puis quand la session est réactivée, l'objet
est... réinstancié à partir des données désérialisées. Te dire si PHP
désérialise toute la session et instancie toutes les variables qu'elle
contient dès le début, ou seulement si tu tentes réellement d'accéder à
$SESSION['toto'] dans le script courant, je ne sais pas.
Je sais que les sessions ne sont pas un dépotoir :), mais je sais aussi
que la création des objets est ce qui prend le plus de temps en
développement orienté objet.
Leur sérialisation et désérialisation sur disque, c'est encore pire :-)
Donc si tu peux stocker tes sessions PHP en mémoire, ne te prive pas.
La vraie question est de savoir si les données (les propriétés de cet
objet) ont une raison valide de transiter sur le réseau entre le client
et le serveur. C'est là que tu vas perdre du temps, si tu fais des
aller-retours inutiles. Le temps passé à instancier l'objet à partir des
données, qu'elles viennent par http ou depuis le disque dur de la
machine est négligeable devant le temps mis à les transférer sur une
ligne RTC ou à les lire sur disque...
Quand tu es dans une application de type daemon ou appli grahique, bref,
un truc qu'on lance et qui tourne "un certain temps" avant de s'arrêter,
il faut en effet faire attention à la rémanence des données en mémoire
(structures ou objets, peu importe). Dans le cadre de web dynamique, ça
reste du "mode cgi" car les requêtes http sont indépéndantes et sur un
protocole non connecté : il n'y a pas de persistence des objets en
mémoire entre les requêtes, il faut les sérialiser (sur disque ou en
RAM).
Risque-je, pour un gros projet de heurter la limite de la taille mémoire
gérable par la session ?
Bonne question, mais tu peux toi même avoir une idée de la réponse : les
sessions php sont stockées dans des fichiers en standard, des bêtes
fichiers plats. Fais un super objet "énorme" selon les critères de ton
application, mets le en session, et regarde la taille du fichier
résultant.
Ne serait-ce pas mieux de les recréer en fonction du besoin ?
Ceci implique alors que les données nécessaires à les créer transitent
sur le réseau. Est-ce que l'utilisateur peut les modifier ? Si oui,
alors il est de toutes façons inutile de les mettre en session. En
revanche, si c'est seulement pour le plaisir de les faire transiter en
HIDDEN, ça n'aucun intérêt non plus, autant les stocker côté serveur.
Quel sont vos avis sur la question ?
A mon sens, tu ne te poses pas le problème dans le bon ordre. Analyse
d'abord le flux de tes données.
Une session (quel que soit son mode de stockage, native php ou non) est
faite pour deux besoins :
1) conserver une donnée côté serveur pour la comparer avec ce qui arrive
la fois d'après (identifiant de session par exemple, jeton de sécurité
etc...)
2) conserver des données pour éviter de les faire systématiquement
transiter sur toutes les pages (et de refaire les traitements de
validation associés) parce qu'elles sont définies à un niveau N de la
navigation et qu'on en aura pas besoin avant le niveau N+x.
Afin d'éviter de passer mon temps à ré-instancier des objets pendant la durée de la visite du visiteur sur le site, je cree un objet et je le stocke systématiquement en session.
Donc : quand tu stockes l'objet dans le fichier de session il est sérialisé (ses propriétés). Puis quand la session est réactivée, l'objet est... réinstancié à partir des données désérialisées. Te dire si PHP désérialise toute la session et instancie toutes les variables qu'elle contient dès le début, ou seulement si tu tentes réellement d'accéder à $SESSION['toto'] dans le script courant, je ne sais pas.
Je sais que les sessions ne sont pas un dépotoir :), mais je sais aussi que la création des objets est ce qui prend le plus de temps en développement orienté objet.
Leur sérialisation et désérialisation sur disque, c'est encore pire :-) Donc si tu peux stocker tes sessions PHP en mémoire, ne te prive pas.
La vraie question est de savoir si les données (les propriétés de cet objet) ont une raison valide de transiter sur le réseau entre le client et le serveur. C'est là que tu vas perdre du temps, si tu fais des aller-retours inutiles. Le temps passé à instancier l'objet à partir des données, qu'elles viennent par http ou depuis le disque dur de la machine est négligeable devant le temps mis à les transférer sur une ligne RTC ou à les lire sur disque... Quand tu es dans une application de type daemon ou appli grahique, bref, un truc qu'on lance et qui tourne "un certain temps" avant de s'arrêter, il faut en effet faire attention à la rémanence des données en mémoire (structures ou objets, peu importe). Dans le cadre de web dynamique, ça reste du "mode cgi" car les requêtes http sont indépéndantes et sur un protocole non connecté : il n'y a pas de persistence des objets en mémoire entre les requêtes, il faut les sérialiser (sur disque ou en RAM).
Risque-je, pour un gros projet de heurter la limite de la taille mémoire gérable par la session ? Bonne question, mais tu peux toi même avoir une idée de la réponse : les
sessions php sont stockées dans des fichiers en standard, des bêtes fichiers plats. Fais un super objet "énorme" selon les critères de ton application, mets le en session, et regarde la taille du fichier résultant.
Ne serait-ce pas mieux de les recréer en fonction du besoin ? Ceci implique alors que les données nécessaires à les créer transitent
sur le réseau. Est-ce que l'utilisateur peut les modifier ? Si oui, alors il est de toutes façons inutile de les mettre en session. En revanche, si c'est seulement pour le plaisir de les faire transiter en HIDDEN, ça n'aucun intérêt non plus, autant les stocker côté serveur.
Quel sont vos avis sur la question ? A mon sens, tu ne te poses pas le problème dans le bon ordre. Analyse
d'abord le flux de tes données. Une session (quel que soit son mode de stockage, native php ou non) est faite pour deux besoins : 1) conserver une donnée côté serveur pour la comparer avec ce qui arrive la fois d'après (identifiant de session par exemple, jeton de sécurité etc...) 2) conserver des données pour éviter de les faire systématiquement transiter sur toutes les pages (et de refaire les traitements de validation associés) parce qu'elles sont définies à un niveau N de la navigation et qu'on en aura pas besoin avant le niveau N+x.
