II. Introduction, démarche et diagnostic▲
II-A. Introduction - quelques réflexions pour bien démarrer…▲
- Ne recevoir aucune chose pour vraie tant que son esprit ne l'aura clairement et distinctement assimilé e préalablement.
- Trier ses difficultés afin de mieux les examiner et les résoudre.
- Établir un ordre de pensées, en commençant par les plus simples jusqu'aux plus complexes et diverses, et ainsi de les retenir toutes et en ordre.
- Passer toutes les choses en revue afin de ne rien omettre.
Descartes, discours de la méthode.
Toutes ces étapes sont rigoureusement les mêmes lors de la mise en place d'un plan d'amélioration des performances :
1. ne pas appliquer de solutions préconçues : vous risquez de perdre du temps à mettre en place une solution qui ne résout pas votre problème. La première étape est de reproduire les conditions dans lesquelles les performances se dégradent et d'identifier de manière certaine le problème.
2. commencer dans l'ordre : généralement il y a un problème dominant. Il ne sert à rien de résoudre les points secondaires avant le premier. Les performances sont souvent améliorées par les actions les plus simples. Par exemple, s'il y a un problème sur l'accès aux données, on peut obtenir un facteur 100 en travaillant sur les index de la base de données tandis que changer les serveurs permettrait d'obtenir un facteur 4.
3. mettre en place les solutions jusqu'au bout : dans la plupart des cas, il ne se pose pas un, mais plusieurs problèmes de performance. Vous devez les identifier et les résoudre un par un. Vous vous rendrez certainement compte que trouver une première solution n'est que le début de la démarche. L'écueil dans ce cas-là est de croire que ce n'était pas la bonne solution et de l'abandonner pour en chercher une autre plus « universelle ». C'est une erreur. Les performances s'améliorent en accumulant les solutions.
4. procéder de manière itérative : les performances vont s'améliorer après ces premières actions, mais cela ne suffira peut-être pas. Il est important de mesurer le progrès et d'itérer.
II-B. Vue d'ensemble de la démarche▲
II-B-1. Constater le problème de performance▲
Cette étape consiste à chercher les premières pistes d'optimisation. Elle est conduite à l'aide des outils de surveillance de la production. L'objectif est de trouver une orientation à la recherche de solutions dans un des quatre domaines suivants :
- applicatif (Apache - PHP)Â ;
- base de données ;
- réseau ;
- infrastructure matérielle.
NOTE : dans les premières itérations de la démarche, certaines solutions sont évidentes. Dans le cas d'un problème sur une page ou une fonctionnalité précise, il est souvent simple d'identifier rapidement d'où vient le problème. Aussi, si la solution est évidente, il suffit de proposer une correction et de passer directement à l'étape 3.
II-B-2. Reproduire le problème et trouver une solution▲
La deuxième étape consiste à reproduire les conditions dans lesquelles les performances se dégradent. Cela permettra de travailler beaucoup plus rapidement sur le problème, et parfois même sans solliciter l'environnement de production.
Une fois que les conditions dans lesquelles les performances ne sont pas bonnes sont identifiées, il convient de mettre en œuvre et de tester les différentes solutions.
II-B-3. Mise en production et mesure de l'impact▲
Deux éléments perturbent la mesure exacte de l'optimisation apportée :
- les différences entre les environnements : pour des raisons économiques, il est rare d'avoir un environnement de préproduction parfaitement identique à celui de production ;
- les conditions dans lesquelles les performances se dégradent : il est parfois impossible ou trop coûteux de reproduire ces conditions. Par exemple, si les performances se dégradent lors d'un pic d'audience, reproduire l'accès au service de nombreux utilisateurs simultanément peut être complexe.
Aussi, dans bien des cas, la seule mesure valable est faite sur l'environnement de production. C'est pour cela que mettre en place une démarche préalable a beaucoup d'importance. Elle permet de réduire le risque et de réduire le temps nécessaire à la mise en place des dispositifs d'optimisation.
II-C. Établir les premières pistes d'optimisation▲
II-C-1. Ressources touchées▲
Un projet est un assemblage de plusieurs ressources matérielles et logicielles. Aussi, soumise à une forte charge, une de ces ressources est susceptible de limiter la performance de l'ensemble. Les outils de surveillance des infrastructures de production permettent de déterminer quelle ressource est liée à la dégradation des performances.
Parmi les ressources matérielles, il y a :
- CPUÂ ;
- RAMÂ ;
- bande passante ;
- disques durs.
Parmi les ressources logicielles, on peut citer :
- nombre de fichiers ouverts ;
- nombre de cœurs utilisés ;
- nombre de connexions à la base de données.
Afin d'établir des pistes de solutions à étudier, il convient de mesurer l'utilisation des différentes ressources citées ci-dessus afin de déterminer quelles sont celles qui sont exploitées de manière trop intense.
Ces mesures servent aussi à comprendre sous quelles conditions et à quels moments les performances sont moins bonnes. De nombreux outils permettent d'effectuer ces mesures. Ils sont décrits dans les paragraphes suivants.
NOTE : il ne faut pas croire que la libération de la ressource la plus sollicitée permet nécessairement d'améliorer de manière spectaculaire la performance de l'ensemble. Bien souvent, produire une première optimisation va conduire à trouver qu'une autre ressource est saturée à son tour. C'est pourquoi la démarche est itérative.
Dans cette démarche il faut respecter un certain ordre. Les ressources matérielles doivent systématiquement être analysées avant les ressources logicielles (mais cela ne signifie pas que les solutions sont nécessairement matérielles). Par exemple, il faut s'assurer que l'utilisation du CPU par la base de données n'est pas critique avant de se pencher sur la configuration du nombre de connexions à la base de données.
BON À SAVOIR : le disque dur doit être analysé après la RAM en raison du phénomène de SWAP qui fait porter l'excédent de mémoire utilisée par le disque dur lorsque la RAM disponible est insuffisante.
II-C-2. Établir les premières pistes d'optimisation - les outils serveur▲
Si vous savez à quel moment précis se produisent les problèmes de performance, vous pouvez alors utiliser des outils de mesure « temps-réel ». Ces outils sont pour la plupart utilisés en ligne de commande sous Linux.
II-C-2-a. Top▲
La commande TOP est l'outil de monitoring des systèmes Linux par excellence. TOP produit une liste des processus actifs du serveur, et détaille leur consommation de temps processeur (CPU) et de mémoire (RAM). Il indique également la charge moyenne du système sur trois périodes : 1 minute, 5 minutes et 15 minutes. Si cet outil ne permet pas de connaître directement l'origine du problème, ce chiffre aide à confirmer s'il s'agit d'un pic d'activité ou bien si la machine est saturée depuis un certain temps.
NOTE : il est à noter que TOP a été pensé de manière à ne pas faire partie lui-même des processus le plus consommateurs de ressources qu'il mesure.
BON À SAVOIR : TOP est un outil extrêmement utile. Il permet d'identifier les problèmes les plus évidents sur la consommation de RAM et de CPU. En revanche, il est possible que TOP ne détecte aucun problème apparent, alors que votre machine est belle et bien ralentie. Cela se produit notamment si le problème se situe au niveau des accès disque, ou encore au niveau des ressources logicielles.
II-C-2-b. IOstat▲
La commande IOSTAT est utilisée pour contrôler la charge des périphériques entrée/sortie en observant leur temps d'activité par rapport à leur taux de transfert. Cette commande est souvent utile pour harmoniser la charge lecture/écriture entre les différents disques durs.
II-C-2-c. IOtop▲
Si l'accès en lecture/écriture de votre disque est saturé (par exemple trop de requêtes INSERT, UPDATE ou DELETE peuvent surcharger votre disque en écriture), la commande TOP peut s'avérer insuffisante comme exposé ci-dessus. IOTOP présente, de la même manière que TOP, les processus qui consomment le plus de lecture et d'écriture sur votre système.
II-C-2-d. Dstat▲
DSTAT est un outil de mesure transversal. Alors que TOP se spécialise dans l'activité CPU et IOTOP dans les accès disques, DSTAT permet de surveiller l'activité sur le serveur de manière transverse. L'utilisateur peut décider d'afficher des indicateurs tels que l'activité CPU, l'activité des disques, l'activité réseau, etc. côte à côte.
NOTE : ce n'est pas l'outil le plus précis, mais il est très pratique pour comparer rapidement différentes mesures du système. De plus, il permet aisément de réaliser des logs analysables sur un tableur comme Excel ou Open Office Calc.
II-C-3. Établir les premières pistes d'optimisation - les outils client▲
II-C-3-a. Webpagetest.org▲
Webpagetest.org est un site Internet permettant de faire un audit du chargement d'une page web. On retrouve le diagramme chronologique des éléments téléchargés, la check-list des points courants à optimiser, un rendu de la page avec une image au bout de quelques secondes et des graphiques résumant les éléments récupérés.
II-C-3-b. Firebug▲
Firebug est un plugin de Firefox apprécié des développeurs web. Il permet d'inspecter le code HTML en ciblant directement l'élément dans la page, d'éditer le style CSS pour tester le résultat directement, déboguer le JavaScript avec des points d'arrêts et un mode pas à pas et espionner le trafic XMLHttpRequest (Ajax). Tout comme webpagetest.org, Firebug permet de disposer d'un diagramme chronologique du chargement de la page. Firebug étant un outil local, vous pouvez même l'utiliser pour tester votre application en phase de développement.
II-C-3-c. YSlow et Page Speed▲
YSlow et Page Speed sont des extensions de Firebug, respectivement développé par Yahoo et Google, permettant d'analyser les performances du trafic réseau de la page. Ces extensions analysent le code de votre page web et proposent de nombreux conseils d'optimisation de votre code HTML et de votre serveur web (utilisation du cache HTTP, etc.),
BON À SAVOIR : webpagetest.org et YSlow fournissent à peu près les mêmes éléments à une nuance près. webpagetest.org permet de localiser (physiquement) d'où émane la demande. En fonction de ce lieu, les diagrammes chronologiques peuvent varier.
II-C-4. Les outils de monitoring▲
Si vous ne pouvez pas prévoir l'occurrence des problèmes de performance, il sera plus simple de se servir d'outils de monitoring afin de pouvoir accéder à l'historique des mesures de vos ressources.
II-C-4-a. Munin▲
Munin permet de surveiller les différentes ressources de vos serveurs. Un client est installé sur chacune des machines, et les données mesurées sont agrégées à intervalle régulier vers une machine centrale (où le serveur Munin se trouve), et présentées sous forme graphique.
Munin permet, dans son installation la plus simple, de surveiller l'utilisation du disque, de la RAM, du CPU et du réseau. Cet outil est Open Source et il existe de nombreux plugins permettant de mesurer d'autres ressources, telles que :
- les temps de réponse (HTTP response time) ;
- la consommation CPU pour une sélection de processus (multimemory plugin) ;
- taux d'utilisation des connexions MYSQL (mysql_connections)…
BON À SAVOIR : la granularité minimale de Munin (intervalle de temps entre deux mesures) est de 5 minutes. Si vous faites face à des problèmes de performance lors de pics de charge très courts (de 5 à 15 minutes), Munin peut s'avérer insuffisant pour vous apporter des informations suffisamment détaillées.
II-C-4-b. Nagios▲
Nagios est un outil de surveillance de serveurs. Contrairement à Munin, Nagios n'est pas un outil de mesure de l'activité. Il est utilisé uniquement pour remonter des alertes. Extensible avec des plugins, il peut remonter des alertes comme :
- activité CPU trop importante ;
- indisponibilité du serveur web ;
- RAM insuffisante ;
- temps de réponse dégradés…
Lorsqu'une alerte est remontée, l'outil peut être paramétré pour prendre des actions, comme envoyer un mail d'alerte aux administrateurs, ou encore envoyer des SMS.
NOTE : si les problèmes de performance se produisent de manière aléatoire et non reproductible, Nagios peut être utilisé pour vous alerter des problèmes rencontrés. Vous pourrez alors vous connecter au serveur pour effectuer des mesures plus approfondies en temps réel.
II-C-4-c. Autres outils▲
D'autres outils vous permettent de connaître l'activité de votre infrastructure. Par exemple, un outil de web analytics permet de connaître approximativement le nombre de visiteurs sur votre plateforme.
D'autres outils (émergents) vous permettent d'avoir une vision encore plus précise de votre activité. Par exemple Collectd (http://collectd.org) permet de descendre sous la barre des 5 minutes imposée par Munin.
II-C-5. Établir les premières pistes en fonction des ressources▲
II-C-5-a. CPU / RAM▲
Si la piste s'oriente vers une activité critique de la RAM ou du CPU, c'est probablement parce que la commande « TOP » aura indiqué que les processus apache (PHP) ou mysqld (BDD MySQL) consomment une quantité trop importante de ces ressources. Selon le processus concerné, il faudra alors identifier plus précisément la ou les causes de cette activité trop importante :
Apache/PHP : si votre problème se pose sur une page en particulier (sauf la page d'accueil où les problèmes sont souvent liés au nombre de connexions simultanées), il est utile d'analyser le code exécuté par celle-ci pour déceler un potentiel défaut. Si, au contraire, il s'agit de l'ensemble de l'application, c'est certainement dû à un trop grand nombre d'utilisateurs. Il est alors intéressant de mettre en place des mises en cache (côté serveur et côté client) ou des traitements asynchrones afin de limiter l'engorgement lors d'un afflux trop important.
MySQL : une très grande partie des problèmes de performance liés à la base de données peut être résolue en utilisant les index adéquats ou en mutualisant les requêtes. Avant cela, il faut systématiquement établir une liste détaillant à la fois la fréquence de la requête (ou du type de requête) et le coût de cette requête.
Autre processus : vous pourriez constater via « top » qu'un autre processus de votre serveur occupe la totalité de votre temps processeur. Il est alors important d'identifier le coupable. Si vous avez installé d'autres services sur votre serveur, l'un d'entre eux pourrait être le coupable. Par exemple, un problème sur un serveur de mail ou une base de données full-text, etc., pourrait déclencher cette consommation CPU qui ralentirait votre serveur.
Si vous ne connaissez pas le nom du processus, n'hésitez pas à vous aider d'une recherche sur Google pour en apprendre plus. Et si vous êtes persuadés de n'avoir jamais installé le processus incriminé, investiguez ! Votre serveur a peut-être été piraté. C'est certainement le cas si vous laissez un accès SSH disponible depuis Internet avec des mots de passe trop simples. N'oubliez pas qu'un hacker n'a pas besoin des accès « root » pour installer et exécuter ses programmes. Un simple accès utilisateur suffit. Il peut alors transformer votre machine en serveur de fichiers ou bot, et les processus que vous voyez dans « top » sont à coup sûr néfastes. Tirez à vue !
II-C-5-b. Bande passante▲
Pour obtenir une première piste d'optimisation, vous devez rechercher le ou les éléments qui consomment de la bande passante. Par exemple, une page qui renvoie une vidéo de 100 Mo peut dégrader les performances de votre site web si elle est appelée de nombreuses fois.
Apache : la première piste à examiner est les logs Apache afin d'observer combien consomme chaque requête et rechercher quels sont les pages ou les fichiers volumineux. En effet, les logs Apache sont assez flexibles et il est possible de les configurer pour afficher la quantité de données envoyées à chaque requête.
NOTE : lorsqu'on mesure la bande passante du serveur, il est important de garder à l'esprit que le serveur n'est pas le seul à saturer. Votre connexion Internet ADSL saturera certainement avant. Si IOStat ne montre pas de surconsommation réseau, la raison d'un affichage lent pourrait être votre connexion Internet, ou n'importe quel élément réseau entre votre client et votre serveur.
II-C-5-c. Disque dur▲
Vos consommations de RAM et de CPU semblent normales et votre bande passante n'est pas saturée. Il y a de grandes chances que votre disque dur soit le facteur limitant. À moins que votre application n'effectue un très grand nombre de lectures/écritures sur le disque (ouverture et modification de fichiers, création de documents, etc.), il est probable que MySQL soit responsable. En effet, les requêtes MySQL SELECT peuvent provoquer des accès disque en lecture (si le résultat de cette requête n'est pas en cache), et les autres types de requêtes (INSERT, UPDATE, DELETE) font systématiquement des accès en écriture.
II-C-5-d. Aucun de ces points ne semble critique ?▲
Le système peut être « bridé » par ses ressources logicielles ou par des latences réseau.
Quelques pistes : nombre de threads MySQL, nombre de fichiers ouverts simultanément.
II-D. Reproduire le problème & établir le diagnostic▲
II-D-1. Reproduire les problèmes de performance▲
Reproduire les conditions dans lesquelles les performances se dégradent est de plus en plus difficile au fur et à mesure que l'on effectue des optimisations. Or, savoir si l'on fait le bon scénario de test est presque aussi important que de faire la bonne optimisation (celle qui nous permettra vraiment d'améliorer les performances sur l'environnement de production). L'objectif est donc de simuler le fonctionnement de votre site web sur un seul des aspects (base de données, accès disque, etc.).
II-D-1-a. ab▲
ab est un outil d'évaluation des performances de votre serveur web. Il indique le nombre de requêtes par seconde que votre application est capable de prendre en charge. Les deux paramètres principaux sont le nombre de requêtes simultanées ainsi que le nombre total de requêtes à effectuer.
BON À SAVOIR : bien qu'il soit possible d'utiliser d'autres paramètres pour passer des valeurs POST, des cookies, etc., cet outil n'est pas fait pour simuler efficacement l'activité d'un ou plusieurs utilisateurs qui naviguent sur votre site, mais plutôt pour simuler l'arrivée massive d'utilisateurs sur une page. En effet, ab n'intègre pas de notion de scénario, car il ne peut tester qu'une seule URL à la fois.
II-D-1-b. JMeter▲
JMeter est une application que l'on peut déployer sur un poste de travail (il vaut mieux qu'il soit dédié afin que le développeur qui s'en sert puisse travailler pendant les runs de tests). C'est un outil qui permet de simuler un grand nombre de requêtes concurrentes HTTP et donc de simuler le comportement du site avec un grand nombre de visiteurs. L'outil produit une synthèse graphique des résultats du test.
NOTE : dans le cas d'une architecture LAMP, l'outil ne présente d'intérêt que pour les requêtes HTTP. En revanche, il permet de tester beaucoup d'autres éléments annexes (serveurs de mails, connexion JDBC, etc.).
BON À SAVOIR : JMeter n'émule pas complètement un navigateur (contrairement à un outil comme Selenium). Il est donc plus difficile de créer un jeu de tests qui soit représentatif du comportement exact de l'application.
II-D-1-c. Selenium Grid (reproduction de scénario)▲
Selenium est une boite à outils permettant de réaliser des tests en simulant l'activité d'un ou de plusieurs utilisateurs sur un site web. Grâce à un plugin Firefox, vous avez la possibilité « d'enregistrer » un scénario en naviguant sur le site, puis de le rejouer à volonté, en vérifiant que l'affichage des pages est conforme aux attentes.
Selenium Grid vous permet de simuler une montée en charge de votre application en jouant plusieurs fois le même scénario en parallèle. Si vous disposez de suffisamment de ressources, il vous sera possible de reproduire les problèmes de performance.
II-D-1-d. Batchs de requêtes SQL▲
Obtenir la liste de toutes les requêtes faites à la base de données pendant l'exécution d'un scénario représentatif, puis le rejouer vous permettra de simuler l'impact de l'application sur la charge de votre serveur de données.
Pour faire cela, vous pouvez soit écrire dans un journal les requêtes au niveau de l'applicatif, soit configurer MySQL pour tracer toutes les requêtes (paramètre « log » de votre fichier my.ini ou my.cnf).
Vous avez la possibilité de rejouer ce batch de façon unitaire pour mesurer le gain de performance grâce à vos optimisations, mais aussi de lancer plusieurs batchs en parallèle pour simuler un pic activité.
II-D-2. Établir le diagnostic▲
Comme expliqué auparavant, la solution est parfois évidente, il n'est parfois pas nécessaire de pousser plus loin l'analyse de votre problème. En revanche, dans certains cas il faut préciser le diagnostic afin d'appliquer la correction appropriée.
Dans ce cas, il existe des outils et des démarches simples permettant d'investiguer plus en profondeur sur l'utilisation des ressources.
II-D-2-a. Logs Apache▲
SYMPTÔMES : votre site répond correctement en temps normal, mais les temps de réponse se dégradent sous la charge.
Les logs Apache tracent toutes les requêtes faites au serveur Apache. En les configurant correctement, vous aurez la possibilité d'obtenir le temps de réponse de votre site. En utilisant des outils de parsing appropriés (AWStats, Visitors, ou WebLog Expert), vous pourrez facilement visualiser le comportement de votre site en fonction du nombre d'utilisateurs connectés.
II-D-2-b. Logs MySQL (dont slow queries)▲
SYMPTÔMES : MySQL consomme énormément de CPU ou le disque dur sature.
Les logs MySQL retracent l'activité de votre serveur de données. Le journal de log simple (celui configuré par défaut) pourra vous renseigner sur la stabilité du serveur MySQL.
Le fichier de slow queries (il est parfois nécessaire de configurer ce log) liste l'ensemble des requêtes dont la durée d'exécution est supérieure à un seuil donné (lui aussi configurable).
Les requêtes contenues dans ce fichier seront donc celles qui mobilisent le plus le serveur, et donc souvent celles qui devront être optimisées.
Exemple de configuration du log slow queries (dans le fichier de configuration MySQL):
[mysqld]port=3306log_slow_queries= 1long_query_time= [seuil]log-slow-queries= [chemin vers le fichier de log]II-D-2-c. Analyse/parsing de code - Xdebug▲
SYMPTÔMES : PHP consomme énormément de CPU.
La fonction Profiler de Xdebug est un outil qui permet d'analyser les temps d'exécution de votre code PHP. Il permet de savoir combien de temps est passé dans chacune des fonctions du code, et donc de déterminer quelle partie de code est moins performante.
II-D-2-d. MySQLTuner▲
MySQLTuner est un script écrit en Perl qui vous permet d'éprouver une installation MySQL rapidement et de faire des recommandations pour améliorer les performances et la stabilité de la base de données. Il produit un rapport détaillant :
- les possibilités offertes par la configuration en cours ;
- des métriques telles que le nombre de jointures effectuées sans index, hit ratio du cache… ;
- des recommandations à la fois sur la manière d'exécuter les requêtes, et sur les paramètres de configuration à modifier.
II-D-3. Audit de la structure de la BDD▲
La structure de la base de données influence fortement ses performances. Ainsi, il faut s'assurer que vos tables contiennent les index appropriés, que les clés étrangères sont en place.
Vérifiez aussi que les triggers éventuels ne nuisent pas aux performances : si chaque insert dans une table implique l'exécution d'un script complexe, il vaudra mieux mettre en place des batchs SQL asynchrones (quand c'est possible bien sûr).
BON À SAVOIR : si les bonnes pratiques en matière de structure relationnelle des bases de données recommandent le respect des normes (on parle de base de données normée), la complexité de relation entre les différentes tables peut nuire aux performances. Il faut toujours partir d'une base normalisée, celle-ci étant bien plus facile à maintenir. En cas de problème de performance, on effectuera une dénormalisation au cas par cas.
II-D-3-a. Réseau interne/réseau externe▲
Si vous avez séparé votre serveur applicatif et votre base de données, assurez-vous au préalable que votre bande passante n'est pas consommée principalement en interne. En effet, si vous effectuez une grande quantité de requêtes ou des requêtes avec des résultats de taille importante, il est possible que ce soit la raison de la baisse des performances en cas de forte affluence.
De manière générale, vous devez veiller à envoyer le moins de données possible du serveur de base de données vers l'application. Écrivez les requêtes les plus sélectives possible et faites le maximum d'agrégations dans vos requêtes SQL.