J'ai fait développé une application Web destinée à réserver des places
de parkings par Internet, en php5 sur plateforme Linux et SGBD Postgres.
Chaque client authentifié accède à son compte perso, et peut
créer/modifier/supprimer des réservations.
Lors de l'affichage des réservations en cours (idem pour celles qui sont
archivées), l'application remplie un gros tableau $_SESSION[...], à
plusieurs dimensions, contenant *toutes* les informations de chaque
réservation.
Tant qu'on reste sur cette page, elle n'affiche alors que 3 ou 4 champs
parmi ceux présents dans le gros tableau.
Si on désire visualiser le détail d'une réservation, les infos étant
déjà stockées en mémoire, l'affichage est rapide (il faut bien un avantage).
Je me pose des questions:
- N'est-il pas plus judicieux de ne charger que ce que l'on a vraiment
besoin, puis de charger les infos plus détaillées lorsqu'on désire
manipuler une réservation (en y cliquant dessus) ?
- Par rapport à ce qui est fait, j'ai peur que si un client dispose
d'un nombre assez conséquent de réservations, la consommation en mémoire
risque de monter en flèche. Comme les infos sont stockées dans un
tableau "global", je me demande si, lorsqu'il va changer de page:
* le tableau est détruit et la mémoire libérée,
* ou bien si la place mémoire est concervée jusqu'à la fin de la session.
* dans le cas où la mémoire n'est pas libérée sur changement de page,
est-que la destruction du tableau le fera ?
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
Jeremy.J
Bonjour à tous,
Une petite question me turlupine:
J'ai fait développé une application Web destinée à réserver des places de parkings par Internet, en php5 sur plateforme Linux et SGBD Postgres. Chaque client authentifié accède à son compte perso, et peut créer/modifier/supprimer des réservations.
Lors de l'affichage des réservations en cours (idem pour celles qui sont archivées), l'application remplie un gros tableau $_SESSION[...], à plusieurs dimensions, contenant *toutes* les informations de chaque réservation. Tant qu'on reste sur cette page, elle n'affiche alors que 3 ou 4 champs parmi ceux présents dans le gros tableau. Si on désire visualiser le détail d'une réservation, les infos étant déjà stockées en mémoire, l'affichage est rapide (il faut bien un avantage).
Je me pose des questions: - N'est-il pas plus judicieux de ne charger que ce que l'on a vraiment besoin, puis de charger les infos plus détaillées lorsqu'on désire manipuler une réservation (en y cliquant dessus) ? Oui, il vaut mieux charger uniquement les données dont on a besoin.
Lorsque l'on développe une application qui tourne sur un serveur (web), il faut tout faire pour minimiser les ressources système utilisées. Cela me fait penser à un petit dicton : "Less is more" ;-)
- Par rapport à ce qui est fait, j'ai peur que si un client dispose d'un nombre assez conséquent de réservations, la consommation en mémoire risque de monter en flèche. Comme les infos sont stockées dans un tableau "global", je me demande si, lorsqu'il va changer de page:
Je considére que tu parle du tableau global "$_SESSION". Il faut savoir que par défaut, les variables de session (car c'est bien comme ça qu'on les apelle ;-) ) sont stockées sur le serveur sous forme de fichier. Lorsqu'un client affiche une page, le tableau global "$_SESSION" est chargé depuis les données contenues dans le fichier de session. Puis ce tableau est déchargé à la fin de la génération de la page.
* le tableau est détruit et la mémoire libérée, Oui. Mais les données sont toujours conservées dans le fichier de session.
* ou bien si la place mémoire est concervée jusqu'à la fin de la session. Non. La "place mémoire" est bien libérée à la fin de la génération de la
page.
* dans le cas où la mémoire n'est pas libérée sur changement de page, est-que la destruction du tableau le fera ?
Sans commentaire.
Merci de votre aide ou de vos conseils. A votre service ;-)
Sébastien
Bonjour à tous,
Une petite question me turlupine:
J'ai fait développé une application Web destinée à réserver des places
de parkings par Internet, en php5 sur plateforme Linux et SGBD Postgres.
Chaque client authentifié accède à son compte perso, et peut
créer/modifier/supprimer des réservations.
Lors de l'affichage des réservations en cours (idem pour celles qui sont
archivées), l'application remplie un gros tableau $_SESSION[...], à
plusieurs dimensions, contenant *toutes* les informations de chaque
réservation.
Tant qu'on reste sur cette page, elle n'affiche alors que 3 ou 4 champs
parmi ceux présents dans le gros tableau.
Si on désire visualiser le détail d'une réservation, les infos étant
déjà stockées en mémoire, l'affichage est rapide (il faut bien un
avantage).
Je me pose des questions:
- N'est-il pas plus judicieux de ne charger que ce que l'on a
vraiment besoin, puis de charger les infos plus détaillées lorsqu'on
désire manipuler une réservation (en y cliquant dessus) ?
Oui, il vaut mieux charger uniquement les données dont on a besoin.
Lorsque l'on développe une application qui tourne sur un serveur (web),
il faut tout faire pour minimiser les ressources système utilisées. Cela
me fait penser à un petit dicton : "Less is more" ;-)
- Par rapport à ce qui est fait, j'ai peur que si un client dispose
d'un nombre assez conséquent de réservations, la consommation en mémoire
risque de monter en flèche. Comme les infos sont stockées dans un
tableau "global", je me demande si, lorsqu'il va changer de page:
Je considére que tu parle du tableau global "$_SESSION". Il faut savoir
que par défaut, les variables de session (car c'est bien comme ça qu'on
les apelle ;-) ) sont stockées sur le serveur sous forme de fichier.
Lorsqu'un client affiche une page, le tableau global "$_SESSION" est
chargé depuis les données contenues dans le fichier de session. Puis ce
tableau est déchargé à la fin de la génération de la page.
* le tableau est détruit et la mémoire libérée,
Oui. Mais les données sont toujours conservées dans le fichier de session.
* ou bien si la place mémoire est concervée jusqu'à la fin de la
session.
Non. La "place mémoire" est bien libérée à la fin de la génération de la
page.
* dans le cas où la mémoire n'est pas libérée sur changement de
page, est-que la destruction du tableau le fera ?
Sans commentaire.
Merci de votre aide ou de vos conseils.
A votre service ;-)
J'ai fait développé une application Web destinée à réserver des places de parkings par Internet, en php5 sur plateforme Linux et SGBD Postgres. Chaque client authentifié accède à son compte perso, et peut créer/modifier/supprimer des réservations.
Lors de l'affichage des réservations en cours (idem pour celles qui sont archivées), l'application remplie un gros tableau $_SESSION[...], à plusieurs dimensions, contenant *toutes* les informations de chaque réservation. Tant qu'on reste sur cette page, elle n'affiche alors que 3 ou 4 champs parmi ceux présents dans le gros tableau. Si on désire visualiser le détail d'une réservation, les infos étant déjà stockées en mémoire, l'affichage est rapide (il faut bien un avantage).
Je me pose des questions: - N'est-il pas plus judicieux de ne charger que ce que l'on a vraiment besoin, puis de charger les infos plus détaillées lorsqu'on désire manipuler une réservation (en y cliquant dessus) ? Oui, il vaut mieux charger uniquement les données dont on a besoin.
Lorsque l'on développe une application qui tourne sur un serveur (web), il faut tout faire pour minimiser les ressources système utilisées. Cela me fait penser à un petit dicton : "Less is more" ;-)
- Par rapport à ce qui est fait, j'ai peur que si un client dispose d'un nombre assez conséquent de réservations, la consommation en mémoire risque de monter en flèche. Comme les infos sont stockées dans un tableau "global", je me demande si, lorsqu'il va changer de page:
Je considére que tu parle du tableau global "$_SESSION". Il faut savoir que par défaut, les variables de session (car c'est bien comme ça qu'on les apelle ;-) ) sont stockées sur le serveur sous forme de fichier. Lorsqu'un client affiche une page, le tableau global "$_SESSION" est chargé depuis les données contenues dans le fichier de session. Puis ce tableau est déchargé à la fin de la génération de la page.
* le tableau est détruit et la mémoire libérée, Oui. Mais les données sont toujours conservées dans le fichier de session.
* ou bien si la place mémoire est concervée jusqu'à la fin de la session. Non. La "place mémoire" est bien libérée à la fin de la génération de la
page.
* dans le cas où la mémoire n'est pas libérée sur changement de page, est-que la destruction du tableau le fera ?
Sans commentaire.
Merci de votre aide ou de vos conseils. A votre service ;-)
Sébastien
Bruno Desthuilliers
Sebastien Cottalorda wrote: (snip)
Lors de l'affichage des réservations en cours (idem pour celles qui sont archivées), l'application remplie un gros tableau $_SESSION[...], à plusieurs dimensions, contenant *toutes* les informations de chaque réservation. (snip)
Si on désire visualiser le détail d'une réservation, les infos étant déjà stockées en mémoire, l'affichage est rapide (il faut bien un avantage).
"premature optimization is the root of all evil". En clair : à ta place, je me contenterais d'aller chercher les infos utiles au moment voulu. Et si *un jour* apparaissaient des problèmes de perf, de sortir mon profileur - ou tout simplement de mettre un peu plus de moyen côté hard...
Mes 2 centimes...
Sebastien Cottalorda wrote:
(snip)
Lors de l'affichage des réservations en cours (idem pour celles qui sont
archivées), l'application remplie un gros tableau $_SESSION[...], à
plusieurs dimensions, contenant *toutes* les informations de chaque
réservation.
(snip)
Si on désire visualiser le détail d'une réservation, les infos étant
déjà stockées en mémoire, l'affichage est rapide (il faut bien un
avantage).
"premature optimization is the root of all evil". En clair : à ta place,
je me contenterais d'aller chercher les infos utiles au moment voulu. Et
si *un jour* apparaissaient des problèmes de perf, de sortir mon
profileur - ou tout simplement de mettre un peu plus de moyen côté hard...
Lors de l'affichage des réservations en cours (idem pour celles qui sont archivées), l'application remplie un gros tableau $_SESSION[...], à plusieurs dimensions, contenant *toutes* les informations de chaque réservation. (snip)
Si on désire visualiser le détail d'une réservation, les infos étant déjà stockées en mémoire, l'affichage est rapide (il faut bien un avantage).
"premature optimization is the root of all evil". En clair : à ta place, je me contenterais d'aller chercher les infos utiles au moment voulu. Et si *un jour* apparaissaient des problèmes de perf, de sortir mon profileur - ou tout simplement de mettre un peu plus de moyen côté hard...
Mes 2 centimes...
Sebastien Cottalorda
Bruno Desthuilliers wrote:
Sebastien Cottalorda wrote: (snip)
Lors de l'affichage des réservations en cours (idem pour celles qui sont archivées), l'application remplie un gros tableau $_SESSION[...], à plusieurs dimensions, contenant *toutes* les informations de chaque réservation.
(snip)
Si on désire visualiser le détail d'une réservation, les infos étant déjà stockées en mémoire, l'affichage est rapide (il faut bien un avantage).
"premature optimization is the root of all evil". En clair : à ta place, je me contenterais d'aller chercher les infos utiles au moment voulu. Et si *un jour* apparaissaient des problèmes de perf, de sortir mon profileur - ou tout simplement de mettre un peu plus de moyen côté hard...
Mes 2 centimes... Merci de vos conseils, mais, je préfère prévenir que guérir.
Sébastien
Bruno Desthuilliers wrote:
Sebastien Cottalorda wrote:
(snip)
Lors de l'affichage des réservations en cours (idem pour celles qui sont
archivées), l'application remplie un gros tableau $_SESSION[...], à
plusieurs dimensions, contenant *toutes* les informations de chaque
réservation.
(snip)
Si on désire visualiser le détail d'une réservation, les infos étant
déjà stockées en mémoire, l'affichage est rapide (il faut bien un
avantage).
"premature optimization is the root of all evil". En clair : à ta place,
je me contenterais d'aller chercher les infos utiles au moment voulu. Et
si *un jour* apparaissaient des problèmes de perf, de sortir mon
profileur - ou tout simplement de mettre un peu plus de moyen côté hard...
Mes 2 centimes...
Merci de vos conseils, mais, je préfère prévenir que guérir.
Lors de l'affichage des réservations en cours (idem pour celles qui sont archivées), l'application remplie un gros tableau $_SESSION[...], à plusieurs dimensions, contenant *toutes* les informations de chaque réservation.
(snip)
Si on désire visualiser le détail d'une réservation, les infos étant déjà stockées en mémoire, l'affichage est rapide (il faut bien un avantage).
"premature optimization is the root of all evil". En clair : à ta place, je me contenterais d'aller chercher les infos utiles au moment voulu. Et si *un jour* apparaissaient des problèmes de perf, de sortir mon profileur - ou tout simplement de mettre un peu plus de moyen côté hard...
Mes 2 centimes... Merci de vos conseils, mais, je préfère prévenir que guérir.
Sébastien
Bruno Desthuilliers
(snip)
Merci de vos conseils, mais, je préfère prévenir que guérir.
Pareil. C'est justement pour ça que je te conseille de faire au plus
simple.
(snip)
Merci de vos conseils, mais, je préfère prévenir que guérir.
Pareil. C'est justement pour ça que je te conseille de faire au plus
