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

[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.


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]

Bonjour,

Je vais passer pour un nul 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]

Bonjour,

Je vais passer pour un nul 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]

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

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]

Bonjour,

Je vais passer pour un nul 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]

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