A travers un cas client, nous allons vous expliquer comment résoudre un problème de lenteur sur son site Prestashop.

Voici un résumé de notre intervention.

La première étape consiste a identifier où se situe le goulot d’étranglement.

Un site Ecommerce utilise deux systèmes principaux pour fonctionner : sa base de donnée et apache/php.

Etape 1 : Identifier si le problème est lié à PHP ou Mysql

En se connectant au serveur, il suffit d’utiliser la commande « htop » (installation : sudo apt-get install htop).

htop

Ici on voit nettement que Apache utilise 99.9 % du processeur. C’est donc lui notre problème.

Cela peut mettre en cause le code PHP ou alors une demande trop forte sur le serveur.

Dans le cas présent, on voit dans le haut du htop (a ordonner par « CPU% ») un seul processus Apache.

Hors, dans le cas d’une demande forte sur le serveur, on verrait plusieurs lignes Apaches les une sous les autres. Malheureusement, dans le cas d’une demande forte, bien souvent il faut augmenter les ressources du serveur. Toutefois, cela cache souvent un goulot d’étranglement et on ne fait que retarder le problème.

Dans notre cas, notre problème est bien lié à PHP et a certaines demandes précises (1 seul processus Apache à 99.9 %).

Etape 2 : Identifier la page concernée

Dans le cas présent, nous avons pu identifier l’action qui engendre cette montée en charge, il s’agit d’une page spécifique du site.

Nous avons pu l’identifier en utilisant le fichier access.log d’Apache tout en regardant le HTOP en parallèle.

Super ! On sait maintenant que la page www.sample.org/sapage.html engendre cette montée en charge.

Mais comment savoir ce qui ne va pas dans cette page ??

Etape 3 : Utiliser des outils de profiling

Nous devons trouver le code exact qui engendre cette consommation excessive de processeur.

Pour cela, nous demandons à l’hébergeur d’installer xdebug et d’activer l’option : xdebug.profiler_enable_trigger

(Je vous invite à vous créer un petit fichier « <?php phpinfo();  » afin de vérifier que l’hébergeur a bien activé xdebug 😉 )

Cette option, va nous permettre d’appeler la page www.sample.org/sapage.html avec un paramètre spécial : www.sample.org/sapage.html?XDEBUG_PROFILE=true

En appelant cette page, on déclenche le profilage de xdebug et on se retrouve avec un fichier du type « cachegrind.out.30343 » dans le répertoire /tmp du serveur.

Il faut le récupérer et, sur une machine Linux (car sous Windows, je n’ai pas pu faire fonctionner WinCacheGrind il crache à l’ouverture du fichier de profilage), installer kcachegrind.

Maintenant, il n’y a plus qu’a ouvrir kcachegrind et lui dire de charger « cachegrind.out.30343 » (ici 2,3 Go). Dans notre cas précis, voici a quoi ressemble le résultat :

ScreenShot003

Avec un peu de savoir faire, on arrive a identifier que le code passe trop de temps sur la partie Yaml de Prestashop.

Ceci est réellement étrange, car ce n’est pas le code d’un module ou du développement spécifique qui est mis en cause.

Si cela avait été le cas, alors il aurait fallu améliorer le code concerné ou lui créer un système de cache.

Mais, quand on rencontre un problème qui est dans le cœur du noyau d’une solution Open Source, on ne peut pas se dire que c’est lui le problème. Ce n’est pas vraiment possible…

Comment la solution Prestashop, qui est utilisée par autant de personnes, pourrait avoir ce type de problème ?

Donc, la première approche consiste a avoir confiance dans l’outil et ainsi de réfléchir « à l’envers » et ainsi de se remettre en question.

Etape 4 : Le piège se referme

Nous avions remarqué que nos environnements de développement ne ramaient pas autant que le serveur (étrange mais sans pistes, nous ne pouvions deviner la source du problème).

Hors le code et la base de donnée étant similaire entre notre environnement local et le serveur, cela sous entend qu’un élément du serveur pourrait être en cause.

Sachant, maintenant, que notre problématique tournait autour de PHP, nous avons comparé les versions de PHP :

  • Serveur : PHP 5.6
  • Dev : PHP 7.1

Nous avons modifié nos machines locales pour downgrader notre installation de PHP 7.1 à 5.6.

Et là, hooo joie, hooo miracle ! Notre environnement de développement rame ! Tout pareil !

Cela démontre bien que la version de PHP influe directement sur les performances.

Donc, il ne reste plus qu’a passer le serveur en PHP 7.1 (et à repasser notre environnement local en 7.1 🙂 ) pour que le serveur obtienne enfin des performances acceptables.

Bien entendu, si ça ne suffisait pas, il faudrait recommencer tout ce processus afin d’identifier à nouveau la source du problème.

 

En cas de besoin, n’hésitez pas à utiliser les compétences de PliciWeb pour vous aider à résoudre ce type de problème.