yuston Posté 25 Juillet 2008 Partager Posté 25 Juillet 2008 Bonsoir, afin d'améliorer et d'alléger un maximum la charge du serveur, je souhaite savoir quelles sont les méthodes et habitudes à prendre. Premier cas: est-ce plus rapide/léger d'écrire un énorme echo ou plusieurs fois avec ouverture et fermeture de PHP. Bon je sais vous n'avez rien compris à ce que j'ai dit, donc un exemple, concret: <?phpecho '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"><head> <title>'.$title.'</title> <meta name="keywords" content="'.$keywords.'" /> <meta name="description" content="'.$description.'" /></head>';?> ou c'est plus efficace comme ça: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"> <head> <title><?php echo $title; ?></title> <meta name="keywords" content="<?php echo $keywords; ?>" /> <meta name="description" content="<?php echo $description; ?>" /> </head> Deuxième cas: S'il faut stocker juste un nombre, un tout petit bout de texte, il vaut mieux d'enchaîner les fopen, fputs, etc. dans un fichier texte ou c'est plus facile d'utiliser les SGBD genre MySQL? Après stockage de cette information, il faut aussi voir si c'est plus léger de réafficher cette information via MySQL ou via le fichier texte, quelle méthode me conseillez-vous? Bon actuellement je n'ai que ces deux questions en tête Donc je vais m'arrêter là Merci et bonne nuit. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Kioob Posté 25 Juillet 2008 Partager Posté 25 Juillet 2008 Hello, premier cas : je dirais que ça importe peu. Quitte à choisir pour les perfs j'opterais pour l'absence de concaténation (en remplaçant les points par des virgules), et pour la lisibilité la seconde version. Dans les 2 cas je ne suis pas certain que ça change quoi que soit, généralement les optimisations ne se font pas vraiment là dessus. deuxième cas : délicat. S'il y a peu de données, qu'il n'y a que très peu d'écriture, pas besoin d'utiliser de verrous, et que c'est relativement bien codé, alors le fichier sera certainement beaucoup plus performant oui. Mais ça fait beaucoup de "si". Lien vers le commentaire Partager sur d’autres sites More sharing options...
yuston Posté 26 Juillet 2008 Auteur Partager Posté 26 Juillet 2008 premier cas : je dirais que ça importe peu. Quitte à choisir pour les perfs j'opterais pour l'absence de concaténation (en remplaçant les points par des virgules), et pour la lisibilité la seconde version.Dans les 2 cas je ne suis pas certain que ça change quoi que soit, généralement les optimisations ne se font pas vraiment là dessus. Toutes optimisations sont bonnes à prendre Bref, donc euh, quelle est la conclusion? En tous cas, pour les echo j'ai pu jeter un oeil à ce petit test mais n'apporte pas la réponse que je m'attends. Quant au deuxième cas, j'avoue que ça reste délicat et que je n'ai pas la moindre idée Ah maintenant que j'y pense, j'ai un troisième cas Dans quel contexte il vaut mieux utiliser, dans les conditions pour vérifier une égalité, un === ou un ==? Lien vers le commentaire Partager sur d’autres sites More sharing options...
petit-ourson Posté 26 Juillet 2008 Partager Posté 26 Juillet 2008 Toutes optimisations sont bonnes à prendre Je ne partage pas cet avis. Si l'optimisation rend la maintenance plus compliquée et apporte peu, ce n'est pas forcément bon à prendre. ;o) D'autant plus que si tu veux optimiser tes traitements PHP / SQL, je pense que l'idéal est de passer par un système de cache (certes plus compliqué à mettre en place mais certainement la meilleure optimisation) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Kioob Posté 26 Juillet 2008 Partager Posté 26 Juillet 2008 (modifié) Pour être plus précis : faire de grosses concaténations comme dans ton premier exemple n'est certainement pas l'idéal. Faire la même chose sans concaténation ( echo 'chaine 1' , 'chaine2'; ) est mieux, mais à la condition également que l'output_buffering de PHP soit activé (ce qui est le cas si la compression interne à PHP est activée par exemple). En mode "CLI" au contraire il vaut mieux faire les concaténations avant, à cause du "flush" automatique. Frédéric Bouchery avait rédigé un petit article à ce sujet il y a quelques temps ; mais il a visiblement fermé son blog... dommage. Enfin, j'ai beau être assez pointilleux sur pas mal de choses, là je trouve que c'est quand même chipoter Ce que je n'aime pas ce sont les traitements inutiles. Quand tu utilises des doubles quotes à la place de simples quotes, cela implique un traitement d'analyse de la chaine pour y retrouver des variables ; là pour moi c'est effectivement un vrai gaspillage (même si l'impact est ridicule). Mais y aller à coup de concaténation pour éviter d'utiliser les doubles quotes n'est pas plus malin pour autant, le résultat n'étant pas forcément mieux. Il en est de même pour l'opérateur de comparaison : pour moi, par défaut il faut utiliser le triple égal. Ainsi on évite à PHP de faire des "transtypages" souvent inutiles, et c'est plus "rapide". Par contre lorsque tu n'es pas certain du type de tes variables, et que dans le contexte en question une chaine vide est la même chose que NULL ou false, bah le double égal est certainement plus adapté oui. S'intéresser à la consommation des ressources c'est plutôt bien oui, mais dans certaines limites peut être ? Là tu chipotes sur ce genre de choses alors que comme chez beaucoup de monde il y a des chances pour que la compression des pages interne à PHP (zlib.output_compression) ne soit pas activée, bien que l'impact coté visiteur (comme serveur d'ailleurs, le slot Apache étant libéré plus tôt) est certainement plus important. Modifié 26 Juillet 2008 par Kioob Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant