fbpx
Livre Blanc

Améliorer les performances de votre application web

Vous commencez à récolter le fruit de vos efforts, votre site web est un succès - félicitations ! Cependant, vous sentez que votre site devient plus lent et un beau jour, avec encore un peu plus de succès et donc plus de trafic, votre site web ne répond plus... sur une page, sur une fonctionnalité particulière, ou encore de manière globale, en cas de trop forte affluence. Lorsque l'on rencontre des problèmes de performance web, il est souvent trop tard. Le site est déjà en production et l'activité de la société peut être fortement pénalisée. Lorsqu'un site devient lent, plus de 50% des visiteurs arrêtent leur navigation. Pour l'équipe du projet, trouver une solution rapidement devient alors la première préoccupation.

Or, en matière d'optimisation, les solutions sont très nombreuses. Dans la plupart des cas, des solutions sont appliquées les unes après les autres dans la précipitation avec une dépense d'énergie incroyable : les équipes travaillent la nuit, le week-end ... "mais cette fois, c'est sûr, on a la bonne solution " ! Dans la plupart des cas, il faut comprendre que ces solutions uniques et appliquées sans discernement vont vous faire perdre un temps précieux.

Notre conviction est que seule une démarche structurée et rationnelle est la clé pour améliorer les performances web de votre application et passer ce cap difficile. Pas de panique, ce livre blanc est là pour vous aider à mettre en place une telle démarche !

Recevoir le livre blanc

Dans ce livre blanc, découvrez :

  • Comment mettre en place une démarche efficace d'amélioration des performances
  • Quels outils utiliser pour effectuer les différents diagnostics de performances
  • Comment identifier les pistes d'amélioration les plus pertinentes
  • Comment améliorer la gestion de votre bande passante
  • Comment optimiser les performances de votre code
  • Comment paramétrer au mieux votre base de données pour de meilleures performances
Comprenez grâce à ce livre blanc comment mettre un place une démarche pérenne d'amélioration des performances de votre application web !

Adopter la bonne démarche et effectuer un diagnostic

Quelques bonnes pratiques pour bien commencer

« Ne recevoir aucune chose pour vraie tant que son esprit ne l’aura clairement et distinctement assimilé 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.

  1. 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 des données, on peut obtenir un facteur d’amélioration de 100 en travaillant sur les index de la base de données tandis que changer les serveurs permettrait d’obtenir seulement un facteur 4.

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

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

Une démarche en trois étapes

  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

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.

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

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

Etablir les pistes d’amélioration

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.

Ressources matérielles

Ressources logicielles
• CPU

• RAM

• Bande Passante

• Disques Durs

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

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.

Quels outils pour effectuer un diagnostic de performance ?

Les outils d’analyse de performance côté serveur

Si vous savez à quel moment précis se produisent les problèmes de performance, vous pourrez utiliser des outils de mesure « temps-réel » pour la plupart utilisés en ligne de commande.

La commande TOP :

La commande 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.

Il est à noter que TOP a été pensé de manière à ne pas faire partie lui-même des processus les plus consommateurs de ressources qu’il mesure.

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.

IO STATS :

La commande IOSTATS 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.

IO TOP :

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.

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 … côte à côte.

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.

Les outils d’analyse de performance côté client

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.

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, debugger 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 chronologie 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.

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, …).

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.

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.

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.

Il 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 times) ;
  • La consommation CPU pour une sélection de processus (multi memory plugin)
  • Le taux d’utilisation des connections MYSQL (mysql_connections)

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.

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éponses 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.

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.

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.

Les différentes pistes d'amélioration habituelles

Il s’agit ici de présenter les différents axes d’approches en fonction des résultats voulus. Les actions à mettre en place sont décrites dans les parties dédiées dans le livre blanc.

CPU & RAM : optimiser les performances du code et les requêtes à la base de données

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 que la 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.

Autres processus : vous pourriez constater 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. 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 passes 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 sont à coup sûr néfastes. Tirez à vue !

Bande passante : optimiser les contenus

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.

La première piste à examiner sont 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.

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

Disque dur : analyser les requêtes MySQL

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. A moins que votre application n’effectue un très grand nombre de lecture/écriture sur le disque (ouverture et modification de fichiers, création de documents, …), 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.

Pour lire la suite,
télécharger le livre blanc

Votre application web a des problèmes de performance et vous devez trouver (très) rapidement des solutions ? Pas de panique, grâce à livre blanc adoptez la bonne démarche pour mettre en place une amélioration rapide et pragmatique de votre application !