Analyser les lenteurs PHP de votre site avec PHP X‑Ray

Un site qui rame, c’est rare­ment une seule cause. Avant même que votre navi­ga­teur n’af­fiche quoi que ce soit, le ser­veur a déjà fait un tra­vail invi­sible : exé­cu­ter le code PHP qui construit la page. Quand cette étape traîne, l’ou­til PHP X‑Ray, dis­po­nible dans votre cPa­nel, vous aide à savoir pré­ci­sé­ment où part le temps. Dans cet article, vous allez décou­vrir ce que cet outil mesure, com­ment lan­cer une ana­lyse, com­ment lire son rap­port, et en quoi il se dis­tingue d’un autre outil de votre héber­ge­ment, Appli­ca­tion Profiler.

Qu’est-ce que PHP X‑Ray ?

PHP X‑Ray est un outil de diag­nos­tic inté­gré au cPa­nel, dans la sec­tion « Logi­ciel ». Il ana­lyse l’exé­cu­tion PHP d’un site afin d’i­den­ti­fier ce qui consomme le plus de temps pen­dant la géné­ra­tion d’une page : scripts, exten­sions, thèmes, requêtes SQL, fonc­tions lentes ou appels vers des ser­vices externes.

Même si je prends Word­Press comme exemple tout au long de cet article, PHP X‑Ray n’est pas un outil réser­vé à Word­Press. Il fonc­tionne avec n’im­porte quelle appli­ca­tion repo­sant sur PHP : Pres­ta­Shop, Joom­la, Dru­pal ou un déve­lop­pe­ment sur mesure. Dès qu’un site est lent et que la cause se situe côté ser­veur, il peut vous aider à iso­ler le problème.

Un point impor­tant à gar­der en tête : PHP X‑Ray ne cor­rige rien. C’est un outil de mesure. Il vous montre où se situe la len­teur, mais la cor­rec­tion reste à votre charge, ou à celle de votre déve­lop­peur, selon le com­po­sant en cause.

Quand l’utiliser ?

PHP X‑Ray devient utile dès que votre site pré­sente des signes de len­teur côté ser­veur. Par exemple :

• des len­teurs régu­lières ou qui appa­raissent par intermittence ;
• un temps de char­ge­ment éle­vé sur cer­taines pages ;
• une admi­nis­tra­tion Word­Press (ou un back-office Pres­ta­Shop) qui répond lentement ;
• des pics de consom­ma­tion pro­ces­seur ou disque ;
• un doute sur une exten­sion, un thème ou un déve­lop­pe­ment spécifique.

À l’in­verse, PHP X‑Ray ne vous sera d’au­cune aide pour une len­teur qui se joue dans le navi­ga­teur, comme un script JavaS­cript externe trop lourd. Son champ d’a­na­lyse s’ar­rête à ce que fait le ser­veur. Il peut tou­te­fois mon­trer qu’un appel externe coûte du temps côté PHP, sou­vent sous une forme tech­nique comme curl_exec. Il donne alors une piste, mais pas for­cé­ment l’i­den­ti­té exacte du ser­vice appelé.

Lancer une analyse

Depuis l’in­ter­face PHP X‑Ray, le bou­ton « Start tra­cing » ouvre le for­mu­laire de confi­gu­ra­tion d’une ana­lyse. Vous y ren­sei­gnez deux élé­ments essen­tiels : le domaine à ana­ly­ser, choi­si dans le menu dérou­lant, et un masque d’URL dans le champ « Spe­ci­fy mask ».

Le masque indique quelles pages sur­veiller. Pour cap­tu­rer lar­ge­ment les pages d’un site, uti­li­sez un masque large, par exemple /* si vous sou­hai­tez cou­vrir l’ensemble des che­mins du domaine. C’est aus­si ce qui vous per­met de cibler une page pré­cise plu­tôt que tout le site : indi­quez son che­min, par exemple /boutique/* pour ne tra­cer que les pages de la bou­tique. Pra­tique quand vous savez déjà quelle page pose pro­blème, car vous évi­tez de mélan­ger des requêtes sans rap­port. Le lien « How to use spe­cial cha­rac­ters ? », à côté du champ, détaille la syn­taxe com­plète si vous vou­lez aller plus loin.

Dans son mode par défaut, PHP X‑Ray trace les 20 pre­mières requêtes reçues sur l’URL indi­quée, ce qui suf­fit dans la plu­part des cas. Si vous avez besoin de plus de maî­trise, la case « Advan­ced set­tings » déver­rouille des réglages sup­plé­men­taires. Vous pou­vez y fil­trer par adresse IP (le carac­tère * signi­fie « toutes les IP »), pra­tique pour ne tra­cer que vos propres visites sur un site déjà fré­quen­té. Vous y choi­sis­sez aus­si l’é­ten­due du test, selon deux modes au choix : par nombre de requêtes (« Request »), réglable de 1 à 100, ou par durée (« Time per­iod »), com­prise entre 1 minute et 2 jours au maxi­mum. Le bou­ton « Run » démarre l’enregistrement.

Une fois l’a­na­lyse lan­cée, elle se nour­rit des visites du site. Sur un site à fort tra­fic, les requêtes des inter­nautes suf­fisent à ali­men­ter l’analyse en quelques ins­tants, sans rien faire de par­ti­cu­lier. Sur un site peu fré­quen­té, ou pour repro­duire une action pré­cise, c’est à vous de géné­rer le tra­fic : ouvrez les pages concer­nées dans votre navi­ga­teur, repro­dui­sez l’ac­tion lente (une recherche, l’a­jout au panier, l’ou­ver­ture du tableau de bord), et répé­tez l’o­pé­ra­tion autant de fois que néces­saire selon le nombre de requêtes confi­gu­ré. Reve­nez ensuite dans PHP X‑Ray pour consul­ter les résultats.

Vous pou­vez uti­li­ser PHP X‑Ray sur un site en pro­duc­tion sans crainte pour son inté­gri­té : l’ou­til se contente d’ob­ser­ver l’exé­cu­tion PHP, il ne modi­fie ni votre site ni vos don­nées, et reste invi­sible pour vos visi­teurs. Une réserve tou­te­fois : pen­dant le tra­çage, l’é­di­teur Cloud­Li­nux indique un sur­coût de l’ordre de 5 à 10 % sur le temps de char­ge­ment. C’est sans consé­quence en pra­tique, car une ana­lyse est tou­jours bor­née. Par défaut, elle s’ar­rête au bout de 20 requêtes ; et si vous pas­sez par les réglages avan­cés, vous fixez vous-même cette limite, en nombre de requêtes (jus­qu’à 100) ou en durée (2 jours au maxi­mum). Dans tous les cas, le tra­çage prend fin de lui-même une fois la limite atteinte. C’est aus­si ce qui explique que PHP X‑Ray ne soit pas conçu pour res­ter actif en per­ma­nence.

Quelques détails méritent d’être signa­lés, car ils évitent de perdre du temps :

• Une seule ana­lyse à la fois. PHP X‑Ray n’au­to­rise qu’une trace active simul­ta­né­ment. Pour en lan­cer une nou­velle, arrê­tez d’a­bord la précédente.
• Méfiez-vous des carac­tères spé­ciaux dans le masque. Un masque conte­nant ? ou = peut ne rien cap­tu­rer. En cas de doute, pré­fé­rez un masque large et iden­ti­fiez la bonne page ensuite, dans le rapport.
• Le cache fausse la mesure. Si une page est ser­vie depuis un cache de page, PHP n’est pas réel­le­ment exé­cu­té, et PHP X‑Ray ne mesure alors presque rien. Lors d’un de mes tests : sur un site avec cache, une même page pas­sait de quelques mil­li­se­condes en visi­teur ano­nyme (ser­vie par le cache) à plus d’une demi-seconde une fois connec­té (géné­rée par PHP). Pour diag­nos­ti­quer un site qui uti­lise un cache, pla­cez-vous donc dans des condi­tions où le code s’exé­cute vrai­ment : navi­guez en étant connec­té, car les caches de page excluent géné­ra­le­ment les uti­li­sa­teurs iden­ti­fiés, ou tes­tez une page jamais mise en cache comme le tableau de bord. Pour com­prendre quel cache agit sur votre site, consul­tez notre guide d’aide à la déci­sion sur le cache.
• Si la cap­ture reste vide, rechar­gez la confi­gu­ra­tion PHP. Il arrive que le tra­cing reste à zéro alors que tout semble cor­rect. Dans ce cas, une astuce effi­cace : dans le cPa­nel, ouvrez PHP puis Options, modi­fiez puis enre­gis­trez n’im­porte quel réglage (vous pou­vez même le remettre à sa valeur d’o­ri­gine). Cette opé­ra­tion force un rechar­ge­ment du moteur PHP, ce qui réac­tive la col­lecte. C’est une mani­pu­la­tion que j’ai dû employer plu­sieurs fois pour déblo­quer une cap­ture récalcitrante.
• Lors de mes tests, IPX­ten­der empê­chait la cap­ture. Si le domaine ana­ly­sé uti­lise IPX­ten­der et que PHP X‑Ray reste vide mal­gré des visites réelles, désac­ti­vez tem­po­rai­re­ment IPX­ten­der le temps de l’analyse, atten­dez que la confi­gu­ra­tion soit bien prise en compte, puis relan­cez le tracing.

➔ Conseil pra­tique : avant de lan­cer PHP X‑Ray, notez pré­ci­sé­ment ce que vous vou­lez tes­ter : page pro­duit lente, recherche interne, ajout au panier, tableau de bord Word­Press, etc. Plus le scé­na­rio est clair, plus le rap­port sera facile à interpréter.

Lire et interpréter un rapport

Une fois les requêtes cap­tu­rées, PHP X‑Ray affiche la liste des ses­sions enre­gis­trées, avec pour cha­cune sa durée. Par défaut, un filtre « Slow » met en avant les requêtes jugées lentes. Pen­sez à le reti­rer si vous cher­chez une requête pré­cise qui n’a pas fran­chi ce seuil : sur une base de don­nées peu volu­mi­neuse, une page peut res­ter sous le radar tout en méri­tant un examen.

En ouvrant le détail d’une requête, vous accé­dez au cœur de l’ou­til. Le rap­port est orga­ni­sé en rubriques distinctes :

• les prin­ci­paux pro­blèmes détec­tés, clas­sés par impact ;
• les modules et exten­sions, avec le temps consom­mé par chacun ;
• les requêtes SQL, avec pour chaque requête le fichier et la ligne qui la déclenchent, le module res­pon­sable et, sur­tout, le nombre d’appels ;
• les fonc­tions sys­tème, dont les appels externes comme curl_exec.

C’est cette sépa­ra­tion qui fait la valeur de l’ou­til. Pre­nons un cas concret ren­con­tré pen­dant mes essais : une page exé­cu­tait la même requête SQL des cen­taines de fois. Dans le rap­port, cette requête appa­rais­sait en tête de la rubrique base de don­nées, avec un nombre d’ap­pels affi­ché clai­re­ment et le fichier exact qui la déclen­chait. Pour un pro­prié­taire de site, le diag­nos­tic est immé­diat : une requête lan­cée en boucle pointe vers un pro­blème d’op­ti­mi­sa­tion, sans avoir besoin de lire la moindre ligne de code.

Le tableau ci-des­sous résume com­ment on peut inter­pré­ter ce que montre PHP X‑Ray.

Sur le volet mémoire en par­ti­cu­lier, il est utile de croi­ser les résul­tats de PHP X‑Ray avec l’ou­til d’u­ti­li­sa­tion des res­sources du cPa­nel, pour dis­tin­guer une len­teur d’une véri­table satu­ra­tion. Pour mieux com­prendre ces notions, notre article sur les limites de res­sources CPU, RAM et I/O apporte le contexte nécessaire.

Enfin, le rap­port peut être expor­té au for­mat PDF. C’est pra­tique pour archi­ver un diag­nos­tic ou le trans­mettre à la per­sonne qui inter­vien­dra sur le code.

➔ Bon à savoir. Un rap­port PHP X‑Ray reflète un ins­tant don­né. Si une len­teur est inter­mit­tente, mul­ti­pliez les ana­lyses à dif­fé­rents moments pour la sai­sir dans de bonnes conditions.

PHP X‑Ray et Application Profiler : deux lectures complémentaires

o2switch pro­pose un second outil d’a­na­lyse des per­for­mances ser­veur, Appli­ca­tion Pro­fi­ler. La ques­tion se pose donc natu­rel­le­ment : font-ils double emploi ? La réponse est non. Les deux observent bien la même réa­li­té, le temps pas­sé par PHP à construire une page, mais ils ne la pré­sentent pas de la même façon.

PHP X‑Ray décom­pose le temps par type de trai­te­ment. Il range sépa­ré­ment les requêtes SQL, les appels externes et les modules, et chiffre chaque poste. Appli­ca­tion Pro­fi­ler, lui, res­ti­tue la pile d’ap­pels sous forme de Fla­me­Graph, une repré­sen­ta­tion visuelle où chaque bloc est une fonc­tion PHP : plus un bloc est large, plus il a consom­mé de temps.

J’ai sou­mis la même page lente aux deux outils. Là où PHP X‑Ray iso­lait la requête SQL fau­tive avec son nombre d’ap­pels, Appli­ca­tion Pro­fi­ler rat­ta­chait ce même temps à la fonc­tion Word­Press qui exé­cute les requêtes, wpdb::_do_query, sans détailler la requête elle-même. La len­teur liée au SQL est visible dans les deux cas, mais vu dif­fé­rem­ment : comme une rubrique chif­frée d’un côté, comme une fonc­tion de la pile d’ap­pels de l’autre.

Concrè­te­ment, le choix de l’ou­til dépend de la ques­tion que vous vous posez, et les deux se com­plètent. PHP X‑Ray excelle pour mettre le doigt sur une requête SQL répé­tée ou un appel externe blo­quant, parce qu’il les fait res­sor­tir dans des rubriques dédiées. Appli­ca­tion Pro­fi­ler brille quand vous cher­chez à com­prendre quelle exten­sion ou quel thème alour­dit le ren­du d’une page, car la lar­geur des blocs rend immé­dia­te­ment visible ce qui pèse le plus dans la pile d’appels. Pour décou­vrir le Fla­me­Graph en détail, repor­tez-vous à mon article dédié à Appli­ca­tion Profiler.

Conclusion

PHP X‑Ray sert à répondre à une ques­tion pré­cise : quand une page PHP est lente, où part le temps ? Il décom­pose l’exé­cu­tion en rubriques claires, scripts, requêtes SQL, appels externes, et pointe le fichier res­pon­sable. C’est l’ou­til idéal pour iden­ti­fier une requête répé­tée ou repé­rer une attente liée à un appel externe côté ser­veur. Gar­dez en tête qu’il reste un outil de mesure : il ana­lyse ce que fait le ser­veur, pas ce qui se passe dans le navi­ga­teur comme un script JavaS­cript lent, et il ne cor­rige rien à votre place.

Il ne rem­place pas Appli­ca­tion Pro­fi­ler, il le com­plète : l’un répond à « quelle requête, com­bien de fois », l’autre à « quel com­po­sant PHP pèse le plus ». Une fois le diag­nos­tic posé, la cor­rec­tion reste à mener sur le site, son thème, ses exten­sions ou sa base de don­nées. Si elle sup­pose une inter­ven­tion sur le code, le rap­port, expor­table en PDF, consti­tue une base solide à trans­mettre à votre développeur.