Beaucoup de développeurs PHP considèrent que le langage PHP est un langage interprété. En réalité, il n’en est rien. Le PHP est en réalité un langage compilé dont le mécanisme de compilation est intermédiaire entre une compilation classique et une compilation JIT. Regardons de plus près ce qu’il en est.
Présentation du PHP
Le PHP est un langage informatique très répandu sur le web, souvent connu dans le quatuor LAMP. Et pour cause : il a été développé à l’origine comme langage de script pour générer dynamiquement, côté serveur, du contenu HTML. S’inspirant librement du langage C ou encore du Java, le PHP est plus simple à maîtriser que ces derniers, tout en étant un langage relativement puissant.
Exécution classique d’un script PHP
Concrètement, les scripts PHP sont stockés côté serveur comme du texte portant l’extension .php. Lors de l’accès à un fichier script PHP, le serveur web lance le module PHP qui se charge de l’exécuter. Cette exécution est la plupart du temps faite via le mécanisme suivant :
- Requête au script PHP au serveur web depuis Internet.
- Lancement du module PHP par le serveur web.
- Chargement par le module PHP du script PHP (code source).
- Compilation du script PHP en code exécutable.
- Exécution du code exécutable.
- Libération des ressources.
Ce mécanisme a pour inconvénient de nécessiter la compilation du code exécutable à partir du code source à chaque requête au script PHP, alors que le script PHP ne change pas, la plupart du temps, entre deux requêtes.
Utilisation d’un cache code PHP
L’idée d’un cache code PHP est par conséquent de stocker le résultat de la compilation du code source PHP dans un cache, mémoire ou disque, et d’aller le chercher aux prochaines requêtes au même script, gagnant ainsi du temps.
Avec un cache code PHP, l’accès au script PHP se passe donc ainsi :
- Requête au script PHP au serveur web depuis Internet.
- Lancement du module PHP par le serveur web.
- Chargement par le module PHP du script PHP (code source).
- Vérification de la présence du script PHP sous forme exécutable dans le cache : si code absent du cache, compilation du code en code exécutable, puis stockage dans le cache (le cas échéant, libération du cache du code et données les moins utiles).
- Exécution du code exécutable.
- Libération des ressources (sauf cache).
De cette manière, la compilation du script PHP en code exécutable ne se fait qu’une seule fois pour toutes (dans la limite de l’espace mémoire alloué au cache) au lieu de se faire à chaque requête au script, accélérant ainsi sensiblement le processus.
En général, l’utilisation d’un cache code permet d’accélérer par un facteur 2 à 4 le temps d’exécution d’un script PHP. Cependant, notez bien que le code exécutable produit, lui, n’est en rien accéléré. Seul le temps de compilation disparaît. D’où le gain de vitesse final. La plupart du temps, ce temps de compilation dure de l’ordre de 50 à 100 ms par requête. Aussi, si votre script nécessitant 150 ms à s’exécuter, il ne mettra que 50 à 100 ms à s’exécuter une fois le cache code installé. S’il mettait 30 secondes à s’exécuter, le gain obtenu sera négligeable.
Caches code PHP disponibles
Actuellement, il existe plusieurs caches code PHP sur le marché, dont plusieurs solutions open source :
- eAccelerator,
- APC,
ainsi que des solutions propriétaires, dont :
- ionCube PHP Encoder,
- Zend Optimizer et Zend Platform,
ou encore d’autres solutions moins connues.
Conclusion
Un cache code PHP permet d’accélérer la plupart des scripts PHP gérés par un serveur web. Cependant, dans le cadre d’une optimisation d’un site web, il convient de noter que cette voie n’est pas la seule à explorer, ni même celle qui permet d’obtenir les meilleurs gains de performances.
En effet, dans le cadre d’une optimisation globale, il convient de s’intéresser à la configuration du serveur web lui-même, qu’il s’agisse de la partie logicielle (configuration spécifique à l’application) ou matérielle (prendre un serveur plus puissant revient souvent moins cher que d’en optimiser la configuration logicielle), ou les deux (mettre en place un cluster de serveurs).
L’un des mécanismes les plus efficaces pour améliorer le temps de chargement de pages web est de réduire la quantité de requêtes au serveur par page chargée. Par exemple, une unique feuille de style par page et pour l’ensemble du site suffit amplement la plupart du temps, et bien souvent, plusieurs images distinctes peuvent être rassemblées en une seule, les paramètres de la feuille de style permettant de gérer leur affichage correct.
Un autre mécanisme vise à séparer le serveur de contenu dynamique (PHP, MySQL) du serveur de contenu statique (images, feuilles de style, etc.), sans oublier les mécanismes de cache côté client (ETag, Cache-Expires, etc.)
Tu as un retour d’experience a partager sur eAccelerator ou APC?
J’avais longtemps utilisé eAccelerator avec un grand succès. Depuis que j’ai appris qu’APC serait probablement intégré à PHP 6, j’ai opté pour ce dernier. Les deux sont cependant excellents et similaires dans leur fonctionnement, et permettent un gain de performances équivalent.
A noter par ailleurs que chacune de ces deux solutions propose aussi d’écrire dans le cache des données pouvant être récupérées par la suite par un autre script, directement depuis la mémoire, ce qui permet d’y stocker des choses les plus diverses sans aucun accès à la BDD ou au disque.
A l’époque où je faisais des tests de performances plus poussés avec eAccelerator, j’avais noté que le passage au cache code permettait un gain de vitesse d’un facteur deux. L’utilisation du cache pour le stockage des données, avec la modification du code qui va avec, a permis un gain de performances par un nouveau facteur deux de mes scripts de l’époque.
Je confirme tous ce qui a été dit, sur notre site topic-topos.com (et c’est pas pour faire de la pub), nous avions des temps de chargement qui atteignaient les 20 secondes par page. Faut dire qu’on a une base de donnée assez lourde (quelques centaines de milliers d’articles et d’images). le site a été développé par une web agency!!!!
On a recruté deux informaticiens qui ont travaillé sur
Réductions des requêtes SQL ( temps divisé par 3)
Mise en cache de certains éléments du site (on passe à 3 secondes)
Nouveau serveur plus puissant (entre 1 et 2 secondes)
J’ose espérer que, contrairement à ce que tu indiques, le serveur web ne charge pas le module PHP à chaque requête.
@Romain : Cela dépend de la configuration logicielle du serveur web et du module PHP. Ce chargement peut être explicite (chargement réel dans le cas de PHP en mode CLI), partiellement explicite (chargement initial, avec conservation de l’état en mémoire avec PHP compilé et configuré en FastCGI) ou implicite (PHP compilé en tant que module statique ou dynamique Apache, par exemple).
Sincerement je pourrais pas vous dire, je pense pas qu’on recharge le module php, est ce que vous pouvez m’expliquer comment on peut voir ca sur le site?
Bonjour désolé pour le « revival » de l’article mais juste pour dire une chose, si on a un contenu venant d’une bdd, qui change tout le temps, contenir la requete dans le cache serait donc bete….
@Aeroth : Pourtant, en mettant dans un cache le résultat d’une requête au serveur de bases de données longue à s’exécuter, on peut gagner beaucoup de temps sans pour autant perdre en fonctionnalités importantes. Par exemple, on peut mettre dans le cache le résultat d’une recherche dans un blog ou un forum, sachant que même si ce cache n’est pas très à jour, il n’aura pas ou peu de conséquences sur la qualité du résultat. Compter le nombre de messages dans un forum, ou le nombre d’articles dans uen catégorie de blogs sont des requêtes relativement longues à s’exécuter, et qui ne perdent pas de leur intérêt lorsque leur mise à jour est différée.
Mais l’on pourrait aller plus loin : au lieu de mettre en cache le résultat d’une requête de base de données, on peut tout à fait imaginer de mettre en cache le code HTML résultant. En effet, le code le plus rapide, c’est encore celui que l’on n’exécute pas.
Merci pour ces informations précieuses… j’ai gagné 0.2 secondes par pages en moyenne, ce qui n’est pas négligeable, car mon ordinateur est un minuscule PC aux aptitudes dérisoires alors que mon site web est énorme (>100.000 pages) et que le nombre de pages vues à ce jour est déjà proche de 32.000. Avec le temps, j’ai fini par comprendre que le temps de génération d’une page était confondu avec un envoi de cookies par certains serveurs de test… enfin bref… je me comprends moi-même, mais ce serait trop long pour moi d’être clair.
Gain donc de 6400 secondes de temps cpu par jour => Merci encore.
bonjour ^^ voila malgré c pas le sujet et desole pour ça puisque j’ai pas trouve la solution ^^ voila mon grand probleme mon site il est tellement lourd je veux installer un eaccelerator pour optimise le site voila y’atil une solution pour ça
site khordabox.com
serveur linux
cpanel accelerator 2 blabla voila et merci d’avance
@gadalf : Est-ce qu’il existe une solution pour installer eAccelerator ? Oui, il faut lire la documentation, tout est détaillé. Le cas échéant, demander à son administrateur système. En cas d’absence de celui-ci, en embaucher un. Ce ne sont pas les prestataires en infogérance qui manquent.
Ceci dit, eAccelerator, APC et autres Zend Optimizer ont tous en commun de fonctionner d’une manière fort similaire : ils gardent en cache le bytecode produit après chargement du code source PHP. Concrètement, cela permet de faire gagner 50 à 200 ms par page chargée. Or, ton site met quelque 2 secondes (2.000 ms) à fournir la page HTML. Et ceci pour plusieurs raisons, dont une lenteur évidente à créer la page, réclamant une optimisation côté PHP, mais aussi un problème de bande passante du serveur, semble-t-il. Changer d’hébergeur est peut-être une voie à explorer. Si possible, l’utilisation du module Apache mod_pagespeed peut améliorer la situation, sans la résoudre.
Enfin, tout ceci pourquoi ? Pour un site sans contenu et bourré de mots-clefs placés là en vrac ? Cela porte un nom : le keyword stuffing ou bourrage de mots-clefs, totalement prohibé par les moteurs de recherche. Bref, quels que soient tes efforts en matière d’optimisation des performances, ils n’auront qu’un impact dérisoire sur le trafic issu des moteurs de recherche, notamment, tant que tu ne mettras pas un tant soit peu de contenu sur ton site, actuellement totalement vide. Et inutile d’espérer compter remplir un site de petites annonces exclusivement pour gagner en visibilité : elles ne sont que très, très exceptionnellement suffisantes pour attirer l’intérêt des moteurs de recherche, notamment…
merci pour votre réponse c’est très gentil de ta part donc voila comme tu as dis je change l’hébergeur j’ai remarque aussi ^^ et pour les moteur de recherche j’ai mis un firewall j’ai bloquer les bot puisque ça bof la band passant ^^ enfin je te remercie encore ^^
@gadalf : Tu as bloqué les robots… d’indexation des recherche ? Et le tout via un pare-feu ? Voici une approche originale.