Bonjour, je debute en PHP et j'ai une question concernant les
performances des includes
Supposons que j'ai une page, vue environ 20.000 fois / jour
<?if ($_SESSION["toto"]=="valeur1"){?>
...un bloc de code de 5ko
<?}else{?>
...un autre bloc de code de 5ko
<?}?>
En terme de performance, et de charge du serveur, est il preferable
de garder l'integralite de ce code tel quel (donc un code source de
10ko et des poussieres) ou de mettre les deux blocs en include (donc
avec un code source reduit de moitie mais de frequents appels au
systeme pour l'ouverture des fichiers) ?
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
Thibaut Allender
En terme de performance, et de charge du serveur, est il preferable de garder l'integralite de ce code tel quel (donc un code source de 10ko et des poussieres) ou de mettre les deux blocs en include (donc avec un code source reduit de moitie mais de frequents appels au systeme pour l'ouverture des fichiers) ?
il vaut mieux ouvrir un seul gros fichier que 3 petits...
un test en boucle utilisant la methode decrite dans le thread precedent (Recuperation du temps d'execution d'une requete MYSQL) te le confirmera d'ailleurs
En terme de performance, et de charge du serveur, est il preferable
de garder l'integralite de ce code tel quel (donc un code source de
10ko et des poussieres) ou de mettre les deux blocs en include (donc
avec un code source reduit de moitie mais de frequents appels au
systeme pour l'ouverture des fichiers) ?
il vaut mieux ouvrir un seul gros fichier que 3 petits...
un test en boucle utilisant la methode decrite dans le thread precedent
(Recuperation du temps d'execution d'une requete MYSQL) te le confirmera
d'ailleurs
En terme de performance, et de charge du serveur, est il preferable de garder l'integralite de ce code tel quel (donc un code source de 10ko et des poussieres) ou de mettre les deux blocs en include (donc avec un code source reduit de moitie mais de frequents appels au systeme pour l'ouverture des fichiers) ?
il vaut mieux ouvrir un seul gros fichier que 3 petits...
un test en boucle utilisant la methode decrite dans le thread precedent (Recuperation du temps d'execution d'une requete MYSQL) te le confirmera d'ailleurs
Supposons que j'ai une page, vue environ 20.000 fois / jour <?if ($_SESSION["toto"]=="valeur1"){?> ...un bloc de code de 5ko <?}else{?> ...un autre bloc de code de 5ko <?}?>
En PHP3 : sans hésiter mettre dans des includes car on parse seulement ce dont on a besoin.
En PHP4 : si vraiment ça pose un problème de perfs (mesurer les temps pris pour ce faire, ça tombe bien la question a été posée aujourd'hui ;-)....) alors vérifier si les caches (de page ou d'opcode) n'amélioreraient pas la situation.
Ne pas oublier que le file system a lui aussi un cache de lecture donc que si la page est vraiment demandée souvent, on ne va pas nécessairement relire le fichier à chaque fois sur le disque.
Maintenant entre nous soit dit, si tu en es vraiment à vérifier ce genre de choses pour optimiser ton code parce que tout le reste est au cordeau, laisse tomber et envoie moi vite un CV ;-)
a++ JG
Bonsoir,
Supposons que j'ai une page, vue environ 20.000 fois / jour
<?if ($_SESSION["toto"]=="valeur1"){?>
...un bloc de code de 5ko
<?}else{?>
...un autre bloc de code de 5ko
<?}?>
En PHP3 : sans hésiter mettre dans des includes car on parse seulement
ce dont on a besoin.
En PHP4 : si vraiment ça pose un problème de perfs (mesurer les temps
pris pour ce faire, ça tombe bien la question a été posée aujourd'hui
;-)....) alors vérifier si les caches (de page ou d'opcode)
n'amélioreraient pas la situation.
Ne pas oublier que le file system a lui aussi un cache de lecture donc
que si la page est vraiment demandée souvent, on ne va pas
nécessairement relire le fichier à chaque fois sur le disque.
Maintenant entre nous soit dit, si tu en es vraiment à vérifier ce genre
de choses pour optimiser ton code parce que tout le reste est au
cordeau, laisse tomber et envoie moi vite un CV ;-)
Supposons que j'ai une page, vue environ 20.000 fois / jour <?if ($_SESSION["toto"]=="valeur1"){?> ...un bloc de code de 5ko <?}else{?> ...un autre bloc de code de 5ko <?}?>
En PHP3 : sans hésiter mettre dans des includes car on parse seulement ce dont on a besoin.
En PHP4 : si vraiment ça pose un problème de perfs (mesurer les temps pris pour ce faire, ça tombe bien la question a été posée aujourd'hui ;-)....) alors vérifier si les caches (de page ou d'opcode) n'amélioreraient pas la situation.
Ne pas oublier que le file system a lui aussi un cache de lecture donc que si la page est vraiment demandée souvent, on ne va pas nécessairement relire le fichier à chaque fois sur le disque.
Maintenant entre nous soit dit, si tu en es vraiment à vérifier ce genre de choses pour optimiser ton code parce que tout le reste est au cordeau, laisse tomber et envoie moi vite un CV ;-)
a++ JG
a.du saussay
john gallet nous disait:
(...) mesurer les temps pris pour ce faire, ça tombe bien la question a été posée aujourd'hui ;-)....)
merci a vous deux pour la reponse :)
Maintenant entre nous soit dit, si tu en es vraiment à vérifier ce genre de choses pour optimiser ton code parce que tout le reste est au cordeau, laisse tomber et envoie moi vite un CV ;-)
Euh je commence a peine a m'interesser au PHP depuis une semaine
Disons que je suis un developpeur Coldfusion confirme, et que j'ai deja eu a a bosser dans des cas ou il fallait traquer la moindre milliseconde gaspillee, donc j'essaye de demarrer le PHP correctement
Par contre si tu veux un CV de dev coldfusion, c'est volontiers :)
-- a.du saussay .
john gallet nous disait:
(...) mesurer les temps pris pour ce faire, ça tombe bien la
question a été posée aujourd'hui ;-)....)
merci a vous deux pour la reponse :)
Maintenant entre nous soit dit, si tu en es vraiment à vérifier ce
genre de choses pour optimiser ton code parce que tout le reste
est au cordeau, laisse tomber et envoie moi vite un CV ;-)
Euh je commence a peine a m'interesser au PHP depuis une semaine
Disons que je suis un developpeur Coldfusion confirme, et que j'ai
deja eu a a bosser dans des cas ou il fallait traquer la moindre
milliseconde gaspillee, donc j'essaye de demarrer le PHP
correctement
Par contre si tu veux un CV de dev coldfusion, c'est volontiers :)
(...) mesurer les temps pris pour ce faire, ça tombe bien la question a été posée aujourd'hui ;-)....)
merci a vous deux pour la reponse :)
Maintenant entre nous soit dit, si tu en es vraiment à vérifier ce genre de choses pour optimiser ton code parce que tout le reste est au cordeau, laisse tomber et envoie moi vite un CV ;-)
Euh je commence a peine a m'interesser au PHP depuis une semaine
Disons que je suis un developpeur Coldfusion confirme, et que j'ai deja eu a a bosser dans des cas ou il fallait traquer la moindre milliseconde gaspillee, donc j'essaye de demarrer le PHP correctement
Par contre si tu veux un CV de dev coldfusion, c'est volontiers :)
-- a.du saussay .
john gallet
Euh je commence a peine a m'interesser au PHP depuis une semaine Alors commence par prendre l'habitude concernant les perfs de mesurer
d'abord et de dédocapillidécouper ensuite.
Disons que je suis un developpeur Coldfusion confirme, et que j'ai deja eu a a bosser dans des cas ou il fallait traquer la moindre milliseconde gaspillee, donc j'essaye de demarrer le PHP correctement
Donc premier exercice : écrire une fonction fx_debug() qui admet en entrée une chaîne de caractères, qui donne le temps global écoulé depuis son premier appel dans le script courant, le temps écoulé depuis son dernier appel, et dont le format de sortie est modifiable à volonté selon un define("NIVEAU_TRACE",XXXX); pour ne rien faire du tout, formatter en commentaires html ou en visible et en rouge.
Je ramasse les copies dans 10 minutes ;-)
a++ JG
Euh je commence a peine a m'interesser au PHP depuis une semaine
Alors commence par prendre l'habitude concernant les perfs de mesurer
d'abord et de dédocapillidécouper ensuite.
Disons que je suis un developpeur Coldfusion confirme, et que j'ai
deja eu a a bosser dans des cas ou il fallait traquer la moindre
milliseconde gaspillee, donc j'essaye de demarrer le PHP
correctement
Donc premier exercice : écrire une fonction fx_debug() qui admet en
entrée une chaîne de caractères, qui donne le temps global écoulé depuis
son premier appel dans le script courant, le temps écoulé depuis son
dernier appel, et dont le format de sortie est modifiable à volonté
selon un define("NIVEAU_TRACE",XXXX); pour ne rien faire du tout,
formatter en commentaires html ou en visible et en rouge.
Euh je commence a peine a m'interesser au PHP depuis une semaine Alors commence par prendre l'habitude concernant les perfs de mesurer
d'abord et de dédocapillidécouper ensuite.
Disons que je suis un developpeur Coldfusion confirme, et que j'ai deja eu a a bosser dans des cas ou il fallait traquer la moindre milliseconde gaspillee, donc j'essaye de demarrer le PHP correctement
Donc premier exercice : écrire une fonction fx_debug() qui admet en entrée une chaîne de caractères, qui donne le temps global écoulé depuis son premier appel dans le script courant, le temps écoulé depuis son dernier appel, et dont le format de sortie est modifiable à volonté selon un define("NIVEAU_TRACE",XXXX); pour ne rien faire du tout, formatter en commentaires html ou en visible et en rouge.
Je ramasse les copies dans 10 minutes ;-)
a++ JG
a.du saussay
john gallet nous disait:
Donc premier exercice : écrire une fonction fx_debug() qui admet en entrée une chaîne de caractères, qui donne le temps global écoulé depuis son premier appel dans le script courant, le temps écoulé depuis son dernier appel, et dont le format de sortie est modifiable à volonté selon un define("NIVEAU_TRACE",XXXX); pour ne rien faire du tout, formatter en commentaires html ou en visible et en rouge.
Y'en a une qui repond quasiment au cahier des charges dans la 4eme "User Contributed Note" de http://fr3.php.net/microtime, il lui manque juste la redirection de la sortie vide/commentaire/texte mais ce n'est pas genant dans la mesure ou ce genre de chrono ne doit pas subsister sur un code mis en production
Pfff je m'en tire bien :)
-- a.du saussay .
john gallet nous disait:
Donc premier exercice : écrire une fonction fx_debug() qui admet
en entrée une chaîne de caractères, qui donne le temps global
écoulé depuis son premier appel dans le script courant, le temps
écoulé depuis son dernier appel, et dont le format de sortie est
modifiable à volonté selon un define("NIVEAU_TRACE",XXXX); pour ne
rien faire du tout, formatter en commentaires html ou en visible
et en rouge.
Y'en a une qui repond quasiment au cahier des charges dans la 4eme
"User Contributed Note" de http://fr3.php.net/microtime, il lui
manque juste la redirection de la sortie vide/commentaire/texte mais
ce n'est pas genant dans la mesure ou ce genre de chrono ne doit pas
subsister sur un code mis en production
Donc premier exercice : écrire une fonction fx_debug() qui admet en entrée une chaîne de caractères, qui donne le temps global écoulé depuis son premier appel dans le script courant, le temps écoulé depuis son dernier appel, et dont le format de sortie est modifiable à volonté selon un define("NIVEAU_TRACE",XXXX); pour ne rien faire du tout, formatter en commentaires html ou en visible et en rouge.
Y'en a une qui repond quasiment au cahier des charges dans la 4eme "User Contributed Note" de http://fr3.php.net/microtime, il lui manque juste la redirection de la sortie vide/commentaire/texte mais ce n'est pas genant dans la mesure ou ce genre de chrono ne doit pas subsister sur un code mis en production
Pfff je m'en tire bien :)
-- a.du saussay .
john gallet
Y'en a une qui repond quasiment au cahier des charges dans la 4eme "User Contributed Note" de http://fr3.php.net/microtime,
Ah bon ? Moi je veux qq chose du genre : <?php // phase d'init
... fx_debug("avant appel sgbd"); ...mysql_... fx_debug("fin sgbd, temps passe en base="); ....//traitements_1 fx_debug("apres traitements_1 qui ont pris ms:"); ..//traitements_2 fx_debug("apres traitements_2 qui ont pris ms"); .... fx_debug("fin script:");
?> et que ça te donne en sortie :
avant appel sgbd : 55 55 fin sgbd, temps passe en base= 9 64 apres traitements_1 qui ont pris ms:10 74 apres traitements_2 qui ont pris ms: 15 89 fin script:3 92
Le premier chiffre est toujours le temps écoulé depuis l'appel précédent, ce qui te donne le temps unitaire de chaque traitement, le second est le temps total écoulé depuis le début du script (on pourrait afficher directement le %age pour voir si c'est utile ou non de s'y intéreser).
il lui manque juste la redirection de la sortie vide/commentaire/texte mais ce n'est pas genant dans la mesure ou ce genre de chrono ne doit pas subsister sur un code mis en production
Ahem. Mettons nous en situation. Ca y est l'application tourne depuis 6 mois. Et puis ça monte en charge, ça rame. A ton avis qu'est-ce qui est le plus rapide : - relire tout le code et rajouter des traces en commentaires html pour essayer de diagnostiquer le problème alors qu'on les avait déjà écrites et enlevées après la recette et avant la MEP ? - changer le niveau de traces de "AUCUN" à "DISCRET" pour le temps de résoudre le problème en ayant toujours conservé les appels aux fonctions fx_debug là où ça peut être intéressant ?
Bref c'est ultraclassique : quand tout va bien on met un niveau de traces minimaliste (zéro éventuellement) et si ça va pas on le relève, mais on ne change qu'une seule constante dans un seul fichier !
a++ JG
NB : ceci est totalement indépendant du langage.
Y'en a une qui repond quasiment au cahier des charges dans la 4eme
"User Contributed Note" de http://fr3.php.net/microtime,
Ah bon ? Moi je veux qq chose du genre :
<?php
// phase d'init
...
fx_debug("avant appel sgbd");
...mysql_...
fx_debug("fin sgbd, temps passe en base=");
....//traitements_1
fx_debug("apres traitements_1 qui ont pris ms:");
..//traitements_2
fx_debug("apres traitements_2 qui ont pris ms");
....
fx_debug("fin script:");
?>
et que ça te donne en sortie :
avant appel sgbd : 55 55
fin sgbd, temps passe en base= 9 64
apres traitements_1 qui ont pris ms:10 74
apres traitements_2 qui ont pris ms: 15 89
fin script:3 92
Le premier chiffre est toujours le temps écoulé depuis l'appel
précédent, ce qui te donne le temps unitaire de chaque traitement, le
second est le temps total écoulé depuis le début du script (on pourrait
afficher directement le %age pour voir si c'est utile ou non de s'y
intéreser).
il lui
manque juste la redirection de la sortie vide/commentaire/texte mais
ce n'est pas genant dans la mesure ou ce genre de chrono ne doit pas
subsister sur un code mis en production
Ahem. Mettons nous en situation. Ca y est l'application tourne depuis 6
mois. Et puis ça monte en charge, ça rame. A ton avis qu'est-ce qui est
le plus rapide :
- relire tout le code et rajouter des traces en commentaires html pour
essayer de diagnostiquer le problème alors qu'on les avait déjà écrites
et enlevées après la recette et avant la MEP ?
- changer le niveau de traces de "AUCUN" à "DISCRET" pour le temps de
résoudre le problème en ayant toujours conservé les appels aux fonctions
fx_debug là où ça peut être intéressant ?
Bref c'est ultraclassique : quand tout va bien on met un niveau de
traces minimaliste (zéro éventuellement) et si ça va pas on le relève,
mais on ne change qu'une seule constante dans un seul fichier !
Y'en a une qui repond quasiment au cahier des charges dans la 4eme "User Contributed Note" de http://fr3.php.net/microtime,
Ah bon ? Moi je veux qq chose du genre : <?php // phase d'init
... fx_debug("avant appel sgbd"); ...mysql_... fx_debug("fin sgbd, temps passe en base="); ....//traitements_1 fx_debug("apres traitements_1 qui ont pris ms:"); ..//traitements_2 fx_debug("apres traitements_2 qui ont pris ms"); .... fx_debug("fin script:");
?> et que ça te donne en sortie :
avant appel sgbd : 55 55 fin sgbd, temps passe en base= 9 64 apres traitements_1 qui ont pris ms:10 74 apres traitements_2 qui ont pris ms: 15 89 fin script:3 92
Le premier chiffre est toujours le temps écoulé depuis l'appel précédent, ce qui te donne le temps unitaire de chaque traitement, le second est le temps total écoulé depuis le début du script (on pourrait afficher directement le %age pour voir si c'est utile ou non de s'y intéreser).
il lui manque juste la redirection de la sortie vide/commentaire/texte mais ce n'est pas genant dans la mesure ou ce genre de chrono ne doit pas subsister sur un code mis en production
Ahem. Mettons nous en situation. Ca y est l'application tourne depuis 6 mois. Et puis ça monte en charge, ça rame. A ton avis qu'est-ce qui est le plus rapide : - relire tout le code et rajouter des traces en commentaires html pour essayer de diagnostiquer le problème alors qu'on les avait déjà écrites et enlevées après la recette et avant la MEP ? - changer le niveau de traces de "AUCUN" à "DISCRET" pour le temps de résoudre le problème en ayant toujours conservé les appels aux fonctions fx_debug là où ça peut être intéressant ?
Bref c'est ultraclassique : quand tout va bien on met un niveau de traces minimaliste (zéro éventuellement) et si ça va pas on le relève, mais on ne change qu'une seule constante dans un seul fichier !
a++ JG
NB : ceci est totalement indépendant du langage.
Etienne SOBOLE
"a.du saussay" a écrit dans le message de news:
En terme de performance, et de charge du serveur, est il preferable de garder l'integralite de ce code tel quel (donc un code source de 10ko et des poussieres) ou de mettre les deux blocs en include (donc avec un code source reduit de moitie mais de frequents appels au systeme pour l'ouverture des fichiers) ?
Bon alors moi je vais faire une réponse qui evidement ne va pas te plaire, mais avec le PHP tu dois surtout te consacrer a des optimisation de type algorithmique.
Le "probleme" que tu soulèves est plutot a la charge du system d'exploitation (disons linux) qui va concerver ton fichier de toute façon en mémoire si effectivement il est lu 20000 fois par jour.
Donc comme c'est pas toi qui a fait linux, tu peux oublier ce genre de problème. les gains seront de toutes façon minime par rapport à une requette SQL mieux faite ou un index correctement crée... Et encore on ne parle toujours là que d'optimisation non algorithmique...
bref... faut programmer propre c'est plus important. en plus si tu avais 100 fichiers, t'aurai pas l'idée (enfin j'espere) de tous les regrouper pour que le chargement aille plus vite !!!
Etienne
"a.du saussay" <asa@chabada.invalid> a écrit dans le message de news:
Xns947CABFF41423aSa@193.252.19.141...
En terme de performance, et de charge du serveur, est il preferable
de garder l'integralite de ce code tel quel (donc un code source de
10ko et des poussieres) ou de mettre les deux blocs en include (donc
avec un code source reduit de moitie mais de frequents appels au
systeme pour l'ouverture des fichiers) ?
Bon alors moi je vais faire une réponse qui evidement ne va pas te plaire,
mais avec le PHP tu dois surtout te consacrer a des optimisation de type
algorithmique.
Le "probleme" que tu soulèves est plutot a la charge du system
d'exploitation (disons linux) qui va concerver ton fichier de toute façon en
mémoire si effectivement il est lu 20000 fois par jour.
Donc comme c'est pas toi qui a fait linux, tu peux oublier ce genre de
problème.
les gains seront de toutes façon minime par rapport à une requette SQL mieux
faite ou un index correctement crée...
Et encore on ne parle toujours là que d'optimisation non algorithmique...
bref...
faut programmer propre c'est plus important.
en plus si tu avais 100 fichiers, t'aurai pas l'idée (enfin j'espere) de
tous les regrouper pour que le chargement aille plus vite !!!
En terme de performance, et de charge du serveur, est il preferable de garder l'integralite de ce code tel quel (donc un code source de 10ko et des poussieres) ou de mettre les deux blocs en include (donc avec un code source reduit de moitie mais de frequents appels au systeme pour l'ouverture des fichiers) ?
Bon alors moi je vais faire une réponse qui evidement ne va pas te plaire, mais avec le PHP tu dois surtout te consacrer a des optimisation de type algorithmique.
Le "probleme" que tu soulèves est plutot a la charge du system d'exploitation (disons linux) qui va concerver ton fichier de toute façon en mémoire si effectivement il est lu 20000 fois par jour.
Donc comme c'est pas toi qui a fait linux, tu peux oublier ce genre de problème. les gains seront de toutes façon minime par rapport à une requette SQL mieux faite ou un index correctement crée... Et encore on ne parle toujours là que d'optimisation non algorithmique...
bref... faut programmer propre c'est plus important. en plus si tu avais 100 fichiers, t'aurai pas l'idée (enfin j'espere) de tous les regrouper pour que le chargement aille plus vite !!!
Etienne
Hugues Peeters
Supposons que j'ai une page, vue environ 20.000 fois / jour
<?if ($_SESSION["toto"]=="valeur1"){?> ... un bloc de code de 5ko <?}else{?> ... un autre bloc de code de 5ko <?}?>
En terme de performance, et de charge du serveur, est il preferable de garder l'integralite de ce code tel quel [...] ou de mettre les deux blocs en include [...] ?
Le moteur de PHP4 fonctionne selon un procédé de précompilation PAR FICHIER. Donc si vous utilisez une instruction include() précédée d'une condition, PHP va évaluer la condition avant de lire et de compiler le fichier à inclure. Par conséquent ça peut augmenter les performances. Mais ça dépend du design du script. Si la condition est souvent évaluée dans le sens d'inclure un fichier, le procédé sera contre productif car l'application va faire un appel disque supplémetaire.
Maintenant, avant de se préoccupper de cela, il vaut mieux se préoccuper d'écrire un code facilement lisible et maintenable et se pencher sur le problèmes de performance dans un second temps. Les goulets d'étranglement ne sont pas toujours où on les attends (un programmeur expérimenté comme Martin Fowler soutient d'ailleurs qu'il ne sont JAMAIS où on les attends).
Cordialement,
Hugues Peeters
Supposons que j'ai une page, vue environ 20.000 fois / jour
<?if ($_SESSION["toto"]=="valeur1"){?>
... un bloc de code de 5ko
<?}else{?>
... un autre bloc de code de 5ko
<?}?>
En terme de performance, et de charge du serveur, est il preferable
de garder l'integralite de ce code tel quel [...] ou de mettre les
deux blocs en include [...] ?
Le moteur de PHP4 fonctionne selon un procédé de précompilation PAR
FICHIER. Donc si vous utilisez une instruction include() précédée
d'une condition, PHP va évaluer la condition avant de lire et de
compiler le fichier à inclure. Par conséquent ça peut augmenter les
performances. Mais ça dépend du design du script. Si la condition est
souvent évaluée dans le sens d'inclure un fichier, le procédé sera
contre productif car l'application va faire un appel disque
supplémetaire.
Maintenant, avant de se préoccupper de cela, il vaut mieux se
préoccuper d'écrire un code facilement lisible et maintenable et se
pencher sur le problèmes de performance dans un second temps. Les
goulets d'étranglement ne sont pas toujours où on les attends (un
programmeur expérimenté comme Martin Fowler soutient d'ailleurs qu'il
ne sont JAMAIS où on les attends).
Supposons que j'ai une page, vue environ 20.000 fois / jour
<?if ($_SESSION["toto"]=="valeur1"){?> ... un bloc de code de 5ko <?}else{?> ... un autre bloc de code de 5ko <?}?>
En terme de performance, et de charge du serveur, est il preferable de garder l'integralite de ce code tel quel [...] ou de mettre les deux blocs en include [...] ?
Le moteur de PHP4 fonctionne selon un procédé de précompilation PAR FICHIER. Donc si vous utilisez une instruction include() précédée d'une condition, PHP va évaluer la condition avant de lire et de compiler le fichier à inclure. Par conséquent ça peut augmenter les performances. Mais ça dépend du design du script. Si la condition est souvent évaluée dans le sens d'inclure un fichier, le procédé sera contre productif car l'application va faire un appel disque supplémetaire.
Maintenant, avant de se préoccupper de cela, il vaut mieux se préoccuper d'écrire un code facilement lisible et maintenable et se pencher sur le problèmes de performance dans un second temps. Les goulets d'étranglement ne sont pas toujours où on les attends (un programmeur expérimenté comme Martin Fowler soutient d'ailleurs qu'il ne sont JAMAIS où on les attends).
Cordialement,
Hugues Peeters
a.du saussay
john gallet nous disait:
Ah bon ? Moi je veux qq chose du genre : (...) et que ça te donne en sortie : avant appel sgbd : 55 55 fin sgbd, temps passe en base= 9 64 apres traitements_1 qui ont pris ms:10 74 apres traitements_2 qui ont pris ms: 15 89 fin script:3 92
et ben, c'est exactement ce que fait le bout de code que je citais. On lance le chrono en debut de page chaque fois que l'on souhaite un temps intermediaire, on lui passe un label sous la forme d'une chaine de caracteres et quand on le stoppe il insere en commentaire HTML les temps intermediaires et cumules
Ahem. Mettons nous en situation. Ca y est l'application tourne depuis 6 mois. Et puis ça monte en charge, ça rame. A ton avis qu'est-ce qui est le plus rapide : - relire tout le code (...) - changer le niveau de traces (...).)
Bon, la on est carrement hors topic :) J'ai une troisieme methode, je remonte la version de dev qui, elle, contenait tous les mouchard, je bidouille dedans jusqu'a plus soif et quand elle a reussi la phase de test, je la repasse dans la moulinette qui m'en fera une version de prod (supression des mouchards, des commentaires, des espaces, des CR-LF....) Il est ensuite interdit bien evidemment de toucher a *cette* version de dev qui constitue l'original du site qui tourne
-- a.du saussay .
john gallet nous disait:
Ah bon ? Moi je veux qq chose du genre :
(...)
et que ça te donne en sortie :
avant appel sgbd : 55 55
fin sgbd, temps passe en base= 9 64
apres traitements_1 qui ont pris ms:10 74
apres traitements_2 qui ont pris ms: 15 89
fin script:3 92
et ben, c'est exactement ce que fait le bout de code que je citais.
On lance le chrono en debut de page
chaque fois que l'on souhaite un temps intermediaire, on lui passe
un label sous la forme d'une chaine de caracteres et quand on le
stoppe il insere en commentaire HTML les temps intermediaires et
cumules
Ahem. Mettons nous en situation. Ca y est l'application tourne
depuis 6 mois. Et puis ça monte en charge, ça rame. A ton avis
qu'est-ce qui est le plus rapide :
- relire tout le code (...)
- changer le niveau de traces (...).)
Bon, la on est carrement hors topic :)
J'ai une troisieme methode, je remonte la version de dev qui, elle,
contenait tous les mouchard, je bidouille dedans jusqu'a plus soif
et quand elle a reussi la phase de test, je la repasse dans la
moulinette qui m'en fera une version de prod (supression des
mouchards, des commentaires, des espaces, des CR-LF....)
Il est ensuite interdit bien evidemment de toucher a *cette* version
de dev qui constitue l'original du site qui tourne
Ah bon ? Moi je veux qq chose du genre : (...) et que ça te donne en sortie : avant appel sgbd : 55 55 fin sgbd, temps passe en base= 9 64 apres traitements_1 qui ont pris ms:10 74 apres traitements_2 qui ont pris ms: 15 89 fin script:3 92
et ben, c'est exactement ce que fait le bout de code que je citais. On lance le chrono en debut de page chaque fois que l'on souhaite un temps intermediaire, on lui passe un label sous la forme d'une chaine de caracteres et quand on le stoppe il insere en commentaire HTML les temps intermediaires et cumules
Ahem. Mettons nous en situation. Ca y est l'application tourne depuis 6 mois. Et puis ça monte en charge, ça rame. A ton avis qu'est-ce qui est le plus rapide : - relire tout le code (...) - changer le niveau de traces (...).)
Bon, la on est carrement hors topic :) J'ai une troisieme methode, je remonte la version de dev qui, elle, contenait tous les mouchard, je bidouille dedans jusqu'a plus soif et quand elle a reussi la phase de test, je la repasse dans la moulinette qui m'en fera une version de prod (supression des mouchards, des commentaires, des espaces, des CR-LF....) Il est ensuite interdit bien evidemment de toucher a *cette* version de dev qui constitue l'original du site qui tourne
-- a.du saussay .
a.du saussay
Etienne SOBOLE nous disait:
Bon alors moi je vais faire une réponse qui evidement ne va pas te plaire, mais avec le PHP tu dois surtout te consacrer a des optimisation de type algorithmique.
Merci a tous pour toutes vos reponses
Mais dans le cas qui m'interesse, la seule optimisation dont j'ai a me soucier est bien cette histoire "gros fichier VS includes"
En ligne, il n'y aura pas de traitement, pas la moindre petite requete SQL, toutes les pages sont generees d'avance sur une autre machine.
Le PHP ne servira que pour deux variables de sessions 1 pour la langue 1 pour membre/visiteur
En fonction de ces variables, le site presentera des blocs de contenu qui auront ete calcules d'avance.
Mais pour rester dans un cas plus general, vous avez bien raison, l'optimisation des requetes ou des algorithme est bien plus importante
-- a.du saussay .
Etienne SOBOLE nous disait:
Bon alors moi je vais faire une réponse qui evidement ne va pas te
plaire, mais avec le PHP tu dois surtout te consacrer a des
optimisation de type algorithmique.
Merci a tous pour toutes vos reponses
Mais dans le cas qui m'interesse, la seule optimisation dont j'ai a
me soucier est bien cette histoire "gros fichier VS includes"
En ligne, il n'y aura pas de traitement, pas la moindre petite
requete SQL, toutes les pages sont generees d'avance sur une autre
machine.
Le PHP ne servira que pour deux variables de sessions
1 pour la langue
1 pour membre/visiteur
En fonction de ces variables, le site presentera des blocs de
contenu qui auront ete calcules d'avance.
Mais pour rester dans un cas plus general, vous avez bien raison,
l'optimisation des requetes ou des algorithme est bien plus
importante
Bon alors moi je vais faire une réponse qui evidement ne va pas te plaire, mais avec le PHP tu dois surtout te consacrer a des optimisation de type algorithmique.
Merci a tous pour toutes vos reponses
Mais dans le cas qui m'interesse, la seule optimisation dont j'ai a me soucier est bien cette histoire "gros fichier VS includes"
En ligne, il n'y aura pas de traitement, pas la moindre petite requete SQL, toutes les pages sont generees d'avance sur une autre machine.
Le PHP ne servira que pour deux variables de sessions 1 pour la langue 1 pour membre/visiteur
En fonction de ces variables, le site presentera des blocs de contenu qui auront ete calcules d'avance.
Mais pour rester dans un cas plus general, vous avez bien raison, l'optimisation des requetes ou des algorithme est bien plus importante
