Performance sur l'écriture du code d'une page Html en PHP

[rtb]

Bonjour,
je souhaiterais avoir votre avis sur une question de performance sur la façon de coder vos pages dynamiques.
Est-il préférable (niveau performances ) d'écrire une page entièrement en php ( html y compris) afin que php ne 'saute' pas les parties html mais les écrivent oubien utiliser php uniquement où c'est nessessaire est plus performant ?
Merci pour vos avis.

 

[mrPringle]

Le plus performant est de faire tout en php, mais il faut aussi penser à la lisibilité du code.
Sinon, tu peux lire cet article avec quelques petits comparatifs usuels afin d'améliorer "légèrement" les temps de traitement : http://www.vulgarisation-informatique.c ... er-php.php

 

[Rod la Kox]

Ah ouais ???
Bas, je ne suis pas d'accord du tout.

Ce qu'il faut, c'est alléger la charge de chaque machine.

Le navigateur devra dans tous les cas interpreter le HTML. Il faut donc allèger le travail du serveur, et donc, lui donner le moins possible de PHP à traiter.

<?php
...des calculs, des appel de bases, des mise en formes...
echo $result;
?>
<p>toto</p>

est plus rapide que

<?php
...des calculs, des appel de bases, des mise en formes...
echo $result;
echo "<p>toto</p>";
?>

 

[Bool]

Bonjour,

généralement j'ai tendance à conseiller de s'attaquer aux vrais problèmes avant de se pencher sur ce genre de broutilles.

En vrac, quelques points qui sont vraiment source de ralentissement :
- tout ce qui est accès distant (connexions MySQL, interrogation de flux, etc).
- ne pas fermer les sessions, à cause du mécanisme de verrou mis en place
- la non gestion du cache HTTP
- les inclusions à foison
- regrouper 50 règles de rewriting dans l'.htaccess à la racine du site
- le reverse DNS à chaque page du site
- PHP.

Mais de manière générale j'essaye d'éviter tout ce qui est "traitement inutile" :
- se connecter à la base de données alors qu'on ne fait pas de requête
- utiliser include() au lieu de readfile() quand le fichier ne contient pas de PHP
- utiliser les doubles quotes alors qu'il n'y a pas de variable dans la chaine
- faire faire à PHP du transtypage à foison quand on connait le type des données

etc.

 

[rtb]

Re,
Merci a tous pour ces infos, le lien suivant est intéréssant pour optimiser les détails ;-)

http://www.vulgarisation-informatique.c ... er-php.php

généralement j'ai tendance à conseiller de s'attaquer aux vrais problèmes avant de se pencher sur ce genre de broutilles.

En vrac, quelques points qui sont vraiment source de ralentissement :
- tout ce qui est accès distant (connexions MySQL, interrogation de flux, etc).
- ne pas fermer les sessions, à cause du mécanisme de verrou mis en place
- la non gestion du cache HTTP
- les inclusions à foison
- regrouper 50 règles de rewriting dans l'.htaccess à la racine du site
- le reverse DNS à chaque page du site
- PHP.

Mais de manière générale j'essaye d'éviter tout ce qui est "traitement inutile" :
- se connecter à la base de données alors qu'on ne fait pas de requête
- utiliser include() au lieu de readfile() quand le fichier ne contient pas de PHP
- utiliser les doubles quotes alors qu'il n'y a pas de variable dans la chaine
- faire faire à PHP du transtypage à foison quand on connait le type des données

Merci bien, dans la liste ci dessus, la plupart des problèmes sont traités, reste quand même la gestion du cache HTTP que nous avons laissé de côté, auriez vous des liens pour voir comment régler cela ?
Merci

 

[dadovb]

Script mise en cache pages PHP

 

[Bool]

Ganf ayant fermé son blog depuis un moment, je n'ai trouvé ça que grace à WebArchive... donc ce sera peut être un peu lent :
http://web.archive.org/web/200704061257 ... hez-moi-ca

L'article est je pense suffisant pour comprendre l'implémentation dans PHP.

Sinon après il y a Yahoo et ses best practices, ainsi que l'outil YSlow pour se rendre compte que finalement ce n'est pas le script PHP qui compte le plus.

 

[WebRankInfo]

Merci pour vos contributions très intéressantes (notamment Bool)

 

[rtb]

Merci pour vos réponses, très intéressant ces remarques et articles, et une reco bien mérité a Bool pour son intervention et les sources ;-)

 

[Audiofeeline]

J'aurai tendance à dire comme Rod la Kox, il faut utiliser PHP quand c'est utile en gros. Faire un echo pour afficher du html n'a que très peu d'intérêt.

 

[xTrade]

J'aurai tendance à dire comme Rod la Kox, il faut utiliser PHP quand c'est utile en gros. Faire un echo pour afficher du html n'a que très peu d'intérêt.

Peut-être, mais c'est de l'optimisation inutile.
Cela me fait penser à ceux qui cherchent à optimiser en cherchant toutes les astuces inutiles qui permettent de réduire le code (qui devient illisible, au passage), qui cherchent à savoir si "i++" est plus rapide que "i=i+1" (Si j'utilise la première notation, c'est tout simplement parce qu'elle est à la fois pratique et lisible), qui cherchent à savoir en php s'il vaut mieux utiliser des "" ou des ''.
(Je suis passé par là, il y a bien longtemps)
Pendant ce temps là, toute la structure du programme est bancale et nécessiterait une réelle optimisation.

La stucture des données, du programme en général, la lisibilité du code (même si on perd une milliseconde par script, on gagne un milliard de fois plus en robustesse et en vitesse de développement), les conseils de Bool... me paraissent bien plus importants de savoir si j'utilise un echo ou un print ou rien du tout.

 

[Audiofeeline]

Pas sur que ce soit inutile notamment sur des énormes sites, il y a peut être des "économies de serveur" à faire.
Ça peut être intéressant pour les applications en ligne, faut voir quoi...

 

[polweb]

Merci pour ces infos,

je vais peut être enlever quelques rewritting de mon htaccess.

 

[webmasterlamogere]

pour la gestion de cache, il y a cette version plus complète : http://www.phpsources.org/scripts395-PHP.htm

 

[dabYo]

http://www.phpbuilder.com/columns/weerning20021209.php3

Cet article m'avait bien aidé dans le temps.

Après pour le HTML dans le PHP tout dépend combien de variables on a à afficher. Si il y a de multiples variables, donc de multiples ouvertures/fermetures des balises PHP, il faut tout mettre dans un echo.

Inversement, si il y a beaucoup de HTML avec peu de balises, c'est en HTML.

 

[Robinson]

J'aurai tendance à dire comme Rod la Kox, il faut utiliser PHP quand c'est utile en gros. Faire un echo pour afficher du html n'a que très peu d'intérêt.

Peut-être, mais c'est de l'optimisation inutile.
Cela me fait penser à ceux qui cherchent à optimiser en cherchant toutes les astuces inutiles qui permettent de réduire le code (qui devient illisible, au passage), qui cherchent à savoir si "i++" est plus rapide que "i=i+1" (Si j'utilise la première notation, c'est tout simplement parce qu'elle est à la fois pratique et lisible), qui cherchent à savoir en php s'il vaut mieux utiliser des "" ou des ''.
(Je suis passé par là, il y a bien longtemps)
Pendant ce temps là, toute la structure du programme est bancale et nécessiterait une réelle optimisation.

La stucture des données, du programme en général, la lisibilité du code (même si on perd une milliseconde par script, on gagne un milliard de fois plus en robustesse et en vitesse de développement), les conseils de Bool... me paraissent bien plus importants de savoir si j'utilise un echo ou un print ou rien du tout.

+1
Je suis aussi passé par là. ça n'apporte strictement rien ! Si le serveur est surchargé, ce n'est pas là le problème ^^

Economie serveur ? un serveur devrait toujours avoir une charge inférieure à 1, alors une économie si minime n'a strictement aucune influence.

 

[Rod la Kox]

Peut-être, mais c'est de l'optimisation inutile.

+1

Imagine tous les sites du web qui économisent 2milisecondes de charge serveur les économies d'énergie que ça fait ... Plus de fonte des glaces...


Plus sérieusement, je pense qu'un codeur débutant ne doit pas se prendre la tête avec l'optimisation du code, mais cela doit venir avec l'expérience.
Optimiser sont code, c'est aussi apprendre à mieux s'en servir. :wink:


J'ai un exemple tout con, mais vrai.

Pourquoi les Renault ou les Peugeot ont des jointure de portière d'1cm alors que les BM et Merco n'ont que 5mm ?
Parce les français n'ont pas cherché à optimiser et aujourd'hui, ne savent pas faire...

 

[Genesys]

Sinon après il y a Yahoo et ses best practices, ainsi que l'outil YSlow pour se rendre compte que finalement ce n'est pas le script PHP qui compte le plus.

C'est en général vrai. Mais, à nuancer un peu.

Les bonnes pratiques formalisées par Yahoo doivent être considérées du point de vue de l'expérience-utilisateur : si le chargement des pages de votre site est lent, vos visiteurs iront voir ailleurs. On est tous d'accord là-dessus.

Si je met en place des tests unitaires, c'est probablement parce que je souhaite éviter des goulets d'étranglement au niveau du code.

Certes, je trouve inutile de reprendre un site dans le seul but d'optimiser son code (l'utilisation d'un optimiseur de code ou d'un cache d'opcode évite d'en passer par là). Mais, c'est aussi une bonne pratique de s'assurer que ses scripts soient "robustes et performants" lorsque l'on démarre un nouveau projet. Je dis bien qu'il s'agit d'une bonne pratique. Parce que bien évidemment, si vous êtes pris par le temps, il vaut sans doute mieux vous préoccuper d'abord de la vitesse de chargement de vos pages que de la vitesse d'exécution de vos scripts. Sans oublier pour autant qu'un script lent, c'est aussi un site lent.

 

[tristan.hervouet]

Précison htaccess

Bonjour,

Je vais passer pour un nul :roll: mais : comment fait-on pour mettre ailleurs que dans un htaccess à la racine les règles de rewriting ?

Merci

 

[xTrade]

Certes, je trouve inutile de reprendre un site dans le seul but d'optimiser son code (l'utilisation d'un optimiseur de code ou d'un cache d'opcode évite d'en passer par là). Mais, c'est aussi une bonne pratique de s'assurer que ses scripts soient "robustes et performants" lorsque l'on démarre un nouveau projet. Je dis bien qu'il s'agit d'une bonne pratique. Parce que bien évidemment, si vous êtes pris par le temps, il vaut sans doute mieux vous préoccuper d'abord de la vitesse de chargement de vos pages que de la vitesse d'exécution de vos scripts. Sans oublier pour autant qu'un script lent, c'est aussi un site lent.

Justement, raison de plus si tu es pris par le temps de faire un code clair, compréhensible, facilement maintenable, bien structuré...
Tu gagnes du temps en développement et le code ne sera guère plus lent qu'un truc soit disant optimisé par d'obscures astuces.
S'il est nécessaire de gagner un peu de temps du point de vue utilisateur, virer une ou deux images inutiles aura un impact immédiat sur le temps de chargement de la page plutôt que cherche à virer des boucles dans le script

 

[zeb]

S'il est nécessaire de gagner un peu de temps du point de vue utilisateur, virer une ou deux images inutiles aura un impact immédiat sur le temps de chargement de la page plutôt que cherche à virer des boucles dans le script

Très pertinent comme remarque.

Sinon d'un autre point de vue, l'optimisation passe avant tout par un système de mesure correcte sur le serveur. Sans mesure, les optimisations peuvent très biens être des appauvrissements.

Ensuite l'architecture serveur a aussi son importance, une page web n'est pas forcement le fruit d'une machine et si le code php est exécuté ailleurs que sur le serveur implantant apache, il y a peut être des différences significatives face a une machine regroupant tout.

dans se domaine, un affichage du temps de fabrication de la page peut souvent mettre en évidence la pertinence d'une optimisation majeur du code, de même un système de mesure du temps de chargement (côté client) montrera souvent que c'est dans le contenu graphique du site que les perfs sont a chercher.

 

[Bool]

Re: Précison htaccess

Bonjour,

Je vais passer pour un nul :roll: mais : comment fait-on pour mettre ailleurs que dans un htaccess à la racine les règles de rewriting ?

Hello,

c'est relativement "simple" : actuellement tu as par exemple à la racine du site des dizaines de règles concernant les dossiers /riri/, /fifi/ et /loulou/ .
Si bien que pour la moindre page, image, icône, feuille de style, script JS ou autre sur le site, Apache traite toutes ces expressions régulières. Il suffit d'activer les logs du module rewrite pour s'en rendre compte.

Tandis que si tu crées le dossier /riri/ et y place un fichier .htaccess qui contient les règles concernant ce dossier, non seulement tu facilites grandement la maintenance mais en plus ça fera toujours ça de moins à traiter pour Apache.

C'est d'ailleurs pour cette raison que j'essaye de privilégier un rewriting de type "/section/XXX.html" plutôt que "/section-XXX.html".

Rien de bien extraordinaire donc, mais sur certains sites l'impact est non négligeable (du genre 200 règles de rewriting traitées à chaque requête HTTP...).

 

[tristan.hervouet]

OK

Merci je ne savais pas qu'Apache traitait toutes les règles à chaque fois 8O

Je vais m'y coller...

 

[rikew]

le mieu c'est de placer les regles dans le httpd.conf comme ca les regles sont lu une seule fois au démarrage d'apache et ensuite c'est terminé.

 

[rtb]

Je suis aussi passé par là. ça n'apporte strictement rien ! Si le serveur est surchargé, ce n'est pas là le problème ^^

Economie serveur ? un serveur devrait toujours avoir une charge inférieure à 1, alors une économie si minime n'a strictement aucune influence.

Notre serveur a une charge de 0.8 en moyenne, alors qui a parlé de surcharge serveur ????
C'est juste pour trouver un juste milieu entre lisibilité du code pour le dev, la maintenance et l'alourdissement inutile de la charge serveur ....
On repasse certains sites et il me semblait pertinent de me poser ce genre de question.
A la vue de certain commentaire (merci bool et autres ;-) ), la problématique n'était pas des plus importante, mais cela, nous le savions dèjà, elle a néanmoins permit de mettre en avant certaines omissions bien plus importantes...
D'autres commentaires sur les optimisations et leur importance ?

 

[raljx]

Re: Précison htaccess

Bonjour,

Je vais passer pour un nul :roll: mais : comment fait-on pour mettre ailleurs que dans un htaccess à la racine les règles de rewriting ?

Hello,

c'est relativement "simple" : actuellement tu as par exemple à la racine du site des dizaines de règles concernant les dossiers /riri/, /fifi/ et /loulou/ .
Si bien que pour la moindre page, image, icône, feuille de style, script JS ou autre sur le site, Apache traite toutes ces expressions régulières. Il suffit d'activer les logs du module rewrite pour s'en rendre compte.

Tandis que si tu crées le dossier /riri/ et y place un fichier .htaccess qui contient les règles concernant ce dossier, non seulement tu facilites grandement la maintenance mais en plus ça fera toujours ça de moins à traiter pour Apache.

C'est d'ailleurs pour cette raison que j'essaye de privilégier un rewriting de type "/section/XXX.html" plutôt que "/section-XXX.html".

Rien de bien extraordinaire donc, mais sur certains sites l'impact est non négligeable (du genre 200 règles de rewriting traitées à chaque requête HTTP...).

on peut aussi traiter les regles directement en php ...

 

[Bool]

Oui raljx il y a certainement d'autres possibilités... dépendant également du serveur http utilisé.

rtb : dans la collection "je chipotte", certains ne mettent en production que des versions "minifiés" des sources PHP (comme on le fait pour le JS et les CSS par exemple). Les scripts prennent ainsi moins de place sur le disque (et donc occupe moins de place en mémoire dans le cache disque), et sont à priori légèrement plus rapide à lire puis parser.

Après avec un cache d'opcode derrière, l'intérêt est nettement moins important.

 

[jnj]

base de données et perf.

hello

j'arrive un peu tard s la discussion
dans le passé, j'ai été benchmarkeur chez un constructeur informatique
en clair, avec des outils et des serveurs spécialement bricolés pour, on faisait tourner différentes manières d'écrire un algorithme pour identifier le moins consommateur de ressources

pas juste des tri et autres babioles, non, des applications complètes notamment bancaires. Bref.

plusieurs aspects majeurs sont ressortis de ces années d'expérience. L'un concerne directement ce post.
Moins on accède à la base, plus vite on va. L'écart entre un accès en cache mémoire et un accès réel sur disque dur via Oracle est d'un facteur 1000 en temps et un facteur 10 en consommation de CPU + mémoire.
Accéder à une vue INTERNE est 10 fois plus rapide.
Donc la qualité de l'algorithme prime sur les bricoles de " ou ' etc.
facile à dire ? ben le nombre de fois où j'ai vu des programmes faire des lectures via MySQL à chaque internautes de données qui ne bougent que rarement , c impressionnant.

Exemple : la description d'un iPod nano dans un site de e-commerce
le codeur lambda : à chaque internaute qui veut lire la description détaillée : appel php / MySQL, calculer la page puis afficher viaz le serveur HTTP

un codeur qui optimise : la page est préconstruite en HTML par batch de nuit. à chaque requête sur ipod nano (des milliers chaque jour) on envoie la page HTML direct sans accès MySQL
facteur 100 à 1000 en gain de consommation ressources CPU, mémoire , disque

des exemples comme cela, j'en ai plein ! et optimiser cela est largement plus efficace que de se poser la question ", ', i++ ou i+=1; etc.

 

[Bacteries]

jnj> Oui du cache (HTML) donc (pas forcément besoin de batch d'ailleurs).

Le cumul de tous ces conseils est bon et ce qui "accéléra" le site dépend du site en lui même. Par exemple un site de jeux (genre "élever son phacochère") est lui difficile à mettre en cache car les données varient en permanence.

Et il y a des système pour mettre en cache (pour la BDD), PHP on a un : http://fr.php.net/manual/fr/intro.memcache.php

 

[aeoai]

Excellent fil. Merci

 

[duplex13]

Bonjour,

généralement j'ai tendance à conseiller de s'attaquer aux vrais problèmes avant de se pencher sur ce genre de broutilles.

En vrac, quelques points qui sont vraiment source de ralentissement :
- tout ce qui est accès distant (connexions MySQL, interrogation de flux, etc).
- ne pas fermer les sessions, à cause du mécanisme de verrou mis en place
- la non gestion du cache HTTP
- les inclusions à foison
- regrouper 50 règles de rewriting dans l'.htaccess à la racine du site
- le reverse DNS à chaque page du site
- PHP.

Mais de manière générale j'essaye d'éviter tout ce qui est "traitement inutile" :
- se connecter à la base de données alors qu'on ne fait pas de requête
- utiliser include() au lieu de readfile() quand le fichier ne contient pas de PHP
- utiliser les doubles quotes alors qu'il n'y a pas de variable dans la chaine
- faire faire à PHP du transtypage à foison quand on connait le type des données

etc.

Dans cette liste de bonne pratique, on peut ajouter, si il y a un accès à une base mysql avec un volume de données assez important, l'optimisation de ses requêtes :
- déterminer les requêtes qui prennent beaucoup de temps (pour ma part, je trace chaque exécution de requête dans un fichier texte lorsque je traque les requêtes lentes)
- rechercher les accès aux tables qui ralentissent (sous phpmyadmin : expliquer la requête ou bien ajouter EXPLAIN devant la requête)
- ajouter des index aux bons endroits pour éviter que mysql ne parcourent tout le contenu des grosses tables.