Livre Blanc Performance Web

Dmarche de diagnostic et d'optimisation pour
amliorer les performances d'un site Web.

par The Coding Machine (Expertise, dveloppement et conseil en Informatique (PHP)) (Blog)
Date de publication : 07 juillet 2011
Dernire mise jour :
Vous commencez rcolter le fruit de vos efforts, votre site web est un succs ?
Flicitations ! Cependant, vous sentez que votre site devient plus lent et un beau jour,
avec encore un peu plus de succs et donc plus de trafic, votre site web ne rpond
plus... http://www.thecodingmachine.com/fr/hautes-performances-web
Comprendre de quelle manire aborder ces problmes de performance, rpertorier
l'ensemble des outils et vous permettre de trouver la bonne solution vos problmatiques
de performance, est l'objectif ambitieux de ce livre. N'hsitez pas tlcharger ce livre
blanc au moment de la conception technique de votre projet ou si vous entreprenez une
dmarche d'amlioration des performances.
Il n'est pas toujours ais de comprendre pourquoi son application web ne rpond pas
comme convenu. Il est alors toujours simple de pointer du doigt tel ou tel problme, mais
tes-vous sr que vous les abordez dans le bon ordre et de la bonne manire ?
The Coding Machine se propose dans ce livre blanc de vous prsenter sa dmarche
d'amlioration des performances de vos projets web. Cette dmarche, construite autour
d'expriences diverses et prouves par de nombreux projets (les rfrences The Coding
Machine), a pour objectif de vous faire gagner un temps prcieux dans l'analyse de vos
performances.
Dmarche de diagnostic et d'optimisation pour amliorer les performances d'un site Web. par
The Coding Machine (Expertise, dveloppement et conseil en Informatique (PHP)) (Blog)
1 - Introduction.............................................................................................................................................................4
1-A - Une histoire qui se rpte souvent...............................................................................................................4
1-B - De l'importance de mettre en place un plan d'amlioration continu des performances................................ 4
1-C - qui s'adresse ce livre blanc et comment l'utiliser ?...................................................................................4
1-D - Pourquoi ce livre blanc ?.............................................................................................................................. 5
1-E - propos de The Coding Machine et des auteurs....................................................................................... 5
2 - Introduction, dmarche et diagnostic.....................................................................................................................6
2-A - Introduction - quelques rflexions pour bien dmarrer................................................................................. 6
2-B - Vue d'ensemble de la dmarche.................................................................................................................. 7
2-B-1 - Constater le problme de performance............................................................................................... 7
2-B-2 - Reproduire le problme et trouver une solution...................................................................................7
2-B-3 - Mise en production et mesure de l'impact........................................................................................... 7
2-C - tablir les premires pistes d'optimisation................................................................................................... 8
2-C-1 - Ressources touches........................................................................................................................... 8
2-C-2 - tablir les premires pistes d'optimisation - les outils serveur............................................................ 8
2-C-2-A - Top............................................................................................................................................... 9
2-C-2-B - IOstat........................................................................................................................................... 9
2-C-2-C - IOtop............................................................................................................................................9
2-C-2-D - Dstat............................................................................................................................................ 9
2-C-3 - tablir les premires pistes d'optimisation - les outils client................................................................ 9
2-C-3-A - Webpagetest.org......................................................................................................................... 9
2-C-3-B - Firebug.......................................................................................................................................10
2-C-3-C - YSlow et Page Speed...............................................................................................................10
2-C-4 - Les outils de monitoring.....................................................................................................................10
2-C-4-A - Munin......................................................................................................................................... 10
2-C-4-B - Nagios........................................................................................................................................10
2-C-4-C - Autres outils.............................................................................................................................. 11
2-C-5 - tablir les premires pistes en fonction des ressources....................................................................11
2-C-5-A - CPU / RAM................................................................................................................................11
2-C-5-B - Bande passante........................................................................................................................ 11
2-C-5-C - Disque dur.................................................................................................................................12
2-C-5-D - Aucun de ces points ne semble critique ?................................................................................12
2-D - Reproduire le problme & tablir le diagnostic.......................................................................................... 12
2-D-1 - Reproduire les problmes de performance........................................................................................12
2-D-1-A - ab...............................................................................................................................................12
2-D-1-B - JMeter........................................................................................................................................12
2-D-1-C - Selenium Grid (reproduction de scnario)................................................................................ 13
2-D-1-D - Batchs de requtes SQL...........................................................................................................13
2-D-2 - tablir le diagnostic............................................................................................................................ 13
2-D-2-A - Logs Apache............................................................................................................................. 13
2-D-2-B - Logs MySQL (dont slow queries)..............................................................................................14
2-D-2-C - Analyse/parsing de code - Xdebug...........................................................................................14
2-D-2-D - MySQLTuner..............................................................................................................................14
2-D-3 - Audit de la structure de la BDD.........................................................................................................14
2-D-3-A - Rseau interne/rseau externe................................................................................................. 15
3 - Amliorer la gestion de votre bande passante....................................................................................................15
3-A - Systme de cache HTTP............................................................................................................................15
3-A-1 - Gestion des ETag............................................................................................................................... 16
3-A-2 - Date d'expiration d'une ressource......................................................................................................16
3-B - Rduire le nombre des fichiers...................................................................................................................16
3-B-1 - Limiter le nombre de fichiers CSS et JS............................................................................................16
3-B-2 - Regrouper les images - Sprite........................................................................................................... 17
3-C - Rduire la taille des fichiers....................................................................................................................... 17
3-C-1 - Rduire la taille des images.............................................................................................................. 17
3-C-2 - Limiter le poids des fichiers - Compression Gzip.............................................................................. 17
3-C-3 - Limiter le poids des fichiers - Minimify...............................................................................................17
3-D - Dporter des ressources............................................................................................................................ 18
3-D-1 - Multi-sites............................................................................................................................................18
-2Les sources prsentes sur cette pages sont libres de droits, et vous pouvez les utiliser votre convenance. Par contre la page de prsentation
de ces sources constitue une oeuvre intellectuelle protge par les droits d'auteurs. Copyright - . Aucune reproduction, mme partielle, ne peut
tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez
selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://thecodingmachine.developpez.com/tutoriels/web/demarche-diagnostic-et-optimisation-pour-ameliorer-performance-site-web/?page=page_1/
3-D-2 - Externaliser les ressources - CDN (Content Delivery Network).........................................................18

3-D-3 - ESI (Edge Site Includes)....................................................................................................................18
3-E - Dernires techniques.................................................................................................................................. 19
3-E-1 - Chronologie de chargement............................................................................................................... 19
3-E-2 - Page Speed, module Apache............................................................................................................ 19
3-E-3 - Prcision sur les solutions prsentes...............................................................................................19
- Rendre plus performant votre code PHP - JavaScript........................................................................................ 19
4-A - Stocker les calculs en cache...................................................................................................................... 19
4-A-1 - Envoi sans calcul - cache spcifique................................................................................................. 19
4-A-2 - Memcache.......................................................................................................................................... 20
4-B - Configuration PHP - Apache...................................................................................................................... 20
4-B-1 - APC - Cache PHP..............................................................................................................................20
4-B-2 - Autres paramtrages Apache - PHP..................................................................................................20
4-C - Limiter la consommation de RAM/CPU......................................................................................................21
4-C-1 - FileHandler et ResultSet.................................................................................................................... 21
4-C-2 - Autoload..............................................................................................................................................21
4-D - Dporter l'excution du code......................................................................................................................22
4-D-1 - Mettre en place des traitements asynchrones................................................................................... 22
4-D-2 - Ajax.....................................................................................................................................................22
4-E - viter les fausses optimisations ............................................................................................................23
- Optimiser votre base de donnes MySQL.......................................................................................................... 23
5-A - Gestion des index....................................................................................................................................... 23
5-A-1 - Indexation de la BDD......................................................................................................................... 23
5-A-2 - Les index multi-colonnes....................................................................................................................24
5-A-3 - Cardinalit des index..........................................................................................................................25
5-A-4 - Recherche de contenus text : index FULLTEXT................................................................................ 25
5-A-5 - Moteur full-text spcialis (Lucene, Apache Solr)..............................................................................25
5-B - Agrgation................................................................................................................................................... 26
5-B-1 - Agrgation en batch........................................................................................................................... 26
5-B-2 - Agrgation directe (triggers)...............................................................................................................27
5-C - Optimisation des requtes la base de donnes......................................................................................27
5-C-1 - Rduire le nombre de requtes......................................................................................................... 27
5-C-2 - Optimiser les requtes les plus critiques........................................................................................... 28
5-C-3 - viter les requtes imbriques...........................................................................................................28
5-D - Dnormalisation du modle de donnes....................................................................................................29
5-E - Base de donnes multidimensionnelle....................................................................................................... 30
5-F - Configuration MySQL.................................................................................................................................. 30
5-F-1 - MyISAM vs InnoDB............................................................................................................................ 31
5-F-2 - Taille du cache InnoDB...................................................................................................................... 32
5-F-3 - Nombre de connexions simultanes.................................................................................................. 32
5-F-4 - Nombre de threads.............................................................................................................................32
5-F-5 - Log file................................................................................................................................................ 33
- Rationaliser votre infrastructure........................................................................................................................... 33
6-A - Upgrade.......................................................................................................................................................34
6-B - Clustering.................................................................................................................................................... 34
6-B-1 - Sparer Apache - MySQL.................................................................................................................. 34
6-B-2 - Load-balancing des serveurs Apache................................................................................................ 35
6-B-3 - SQL Master/Slave.............................................................................................................................. 35
6-C - Cloud Computing........................................................................................................................................ 36
- Utilisation - Reproduction - Remerciements........................................................................................................ 37
1 - Introduction
1-A - Une histoire qui se rpte souvent...
Vous commencez rcolter le fruit de vos efforts, votre site web est un succs - flicitations ! Cependant, vous sentez
que votre site devient plus lent et un beau jour, avec encore un peu plus de succs et donc plus de trafic, votre site
web ne rpond plus... sur une page, sur une fonctionnalit particulire, ou encore de manire globale, en cas de
trop forte affluence.
Lorsque l'on rencontre des problmes de performance, il est souvent trop tard. Le site est dj en production
et l'activit de la socit peut tre fortement pnalise. Lorsqu'un site devient lent, plus de 50% des visiteurs arrtent
leur navigation. Pour l'quipe du projet, trouver une solution rapidement devient la premire proccupation. Or, en
matire d'optimisation, les solutions sont trs nombreuses. Dans la plupart des cas, elles sont appliques les unes
aprs les autres dans la prcipitation avec une dpense d'nergie incroyable : les quipes travaillent la nuit, le weekend... "mais cette fois, c'est sr, on a la bonne solution !"
Dans la plupart des cas, il faut comprendre que ces solutions uniques et appliques sans discernement vont vous
faire perdre un temps prcieux. Mme si souvent, on finit quand mme par la trouver, avec un peu de chance et au
prix d'efforts considrables.
Notre conviction est que l'application d'une dmarche structure et rationnelle est la cl pour amliorer les
performances de votre site, afin de passer ce cap difficile. Mme (voire surtout) s'il s'agit d'une situation de
crise .
1-B - De l'importance de mettre en place un plan d'amlioration continu des performances

Au del de l'aspect douloureux des mauvaises performances, il est essentiel de mettre en place un plan d'amlioration
des performances pour au moins deux raisons :
de nombreuses statistiques sur les sites e-Commerce montrent que rduire les temps d'affichage des pages
rduit le taux d'abandon de panier ;
les moteurs de recherche prennent de plus en plus en compte le confort des utilisateurs. Une des seules
mesures leur disposition est le temps de chargement des pages. Amliorer les performances de son site
permet donc d'amliorer son rfrencement naturel.
1-C - qui s'adresse ce livre blanc et comment l'utiliser ?

Ce livre blanc s'adresse l'ensemble des acteurs faisant face des problmes de performance sur des applications
web en production.
NOTE : les conseils portent sur les architectures LAMP (PHP MySQL) mais la plupart
s'appliquent aussi aux applications web de type Java/J2EE ou Ruby.
Nous nous sommes fixs l'objectif de faire un guide qui soit le plus pratique et efficace possible. Nous n'avons
donc pas cherch citer l'ensemble des outils de diagnostic ni rpertorier l'ensemble des solutions. Avec cet
ouvrage, vous devriez facilement comprendre dans quel domaine rechercher une solution et trouver cette
solution dans la plupart des cas.
Il est rare que les performances d'un site (mme si c'est dommage) soient rellement tudies avec attention au
dmarrage du projet, souvent pour des questions de budget. Mais vous pouvez malgr tout utiliser cet ouvrage avant
de mettre votre site en production. La dmarche est identique.
1-D - Pourquoi ce livre blanc ?

De nombreux ouvrages ou articles expliquent des points prcis pour amliorer les performances. Ils dtaillent par
exemple comment amliorer les performances de PHP, comment paramtrer MySQL ou bien encore quelles sont
les meilleures architectures techniques. Pourtant, rares sont ceux qui traitent de la dmarche d'ensemble qu'il faut
suivre pour amliorer les performances une fois l'application dploye.
Les performances de votre site dpendent troitement de votre activit et de l'architecture technique que vous avez
mise en place. Si vous avez un site qui ne prsente que des contenus, le poids des pages et la gestion du cache
seront essentiels et ce qui concerne les optimisations des bases de donnes ou du code n'aura pas ou peu d'impacts
pour vous. Cependant, toute la dmarche, l'outillage et de nombreuses solutions pourront vous tre utiles.
Heureusement, les architectures LAMP sont suffisamment diffuses et classiques pour tre, dans la plupart des
cas, correctement dveloppes. Il est rare qu'une application soit structurellement tellement mal conue qu'il faille
reprendre le projet depuis le dbut.
En revanche, peu de socit disposent la fois de l'exprience et des connaissances permettant de solutionner ces
problmes de performance. Ils sont trop peu frquents pour en faire une spcialit et les problmes rencontrs ont
des solutions dans des domaines de comptence trs diffrents (matriel, base de donnes, dveloppements etc.).
Mettre en place un plan d'amlioration des performances exige de la srnit. Ce qui est rarement le cas lorsque des
problmes de performance se posent. Cet ouvrage vise donc partager l'exprience de The Coding Machine. Il
indique les diffrentes tapes permettant de conduire les diffrentes investigations ncessaires et prsente
les solutions envisageables.
1-E - propos de The Coding Machine et des auteurs

The Coding Machine est une socit de services informatiques spcialise dans les projets innovants. La multiplicit
des projets sur des architectures PHP-MySQL et l'intrt que nous leur portons nous incitent rgulirement publier
des articles de blog lorsque le sujet est court, ou crire des livres blancs lorsque le sujet devient plus vaste.
Ce livre blanc a t crit par David Ngrier, associ directeur technique, Jean-Guillaume Dujardin, associ grant
et Kevin Nguyen, manager de projet web.
Les auteurs de cet ouvrage ainsi que toute l'quipe de TCM se tiennent videmment votre disposition si vous
prouvez des difficults mettre en place ce plan d'actions d'amlioration des performances ou si vous souhaitez
nous faire part d'un problme que nous n'avons pas trait (le sujet est vaste !), partager des lments de rflexion
avec nous ou bien tout simplement nous faire part de vos remarques.
2 - Introduction, dmarche et diagnostic

2-A - Introduction - quelques rflexions pour bien dmarrer...
Ne recevoir aucune chose pour vraie tant que son esprit ne l'aura clairement et distinctement assimil
e pralablement.
Trier ses difficults afin de mieux les examiner et les rsoudre.
tablir un ordre de penses, en commenant 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 mthode.

Toutes ces tapes sont rigoureusement les mmes lors de la mise en place d'un plan d'amlioration des
performances :
1. ne pas appliquer de solutions prconues : vous risquez de perdre du temps mettre en place une solution qui
ne rsout pas votre problme. La premire tape est de reproduire les conditions dans lesquelles les performances
se dgradent et d'identifier de manire certaine le problme.
2. commencer dans l'ordre : gnralement il y a un problme dominant. Il ne sert rien de rsoudre les points
secondaires avant le premier. Les performances sont souvent amliores par les actions les plus simples. Par
exemple, s'il y a un problme sur l'accs aux donnes, on peut obtenir un facteur 100 en travaillant sur les index de
la base de donnes 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
problmes de performance. Vous devez les identifier et les rsoudre un par un. Vous vous rendrez certainement
compte que trouver une premire solution n'est que le dbut de la dmarche. 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'amliorent en accumulant les solutions.
4. procder de manire itrative : les performances vont s'amliorer aprs ces premires actions, mais cela ne
suffira peut tre pas. Il est important de mesurer le progrs et d'itrer.
2-B - Vue d'ensemble de la dmarche
2-B-1 - Constater le problme de performance

Cette tape consiste chercher les premires 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 donnes ;
rseau ;
infrastructure matrielle.
NOTE : dans les premires itrations de la dmarche, certaines solutions sont videntes.
Dans le cas d'un problme sur une page ou une fonctionnalit prcise, il est souvent simple
d'identifier rapidement d'o vient le problme. Aussi, si la solution est vidente, il suffit de
proposer une correction et de passer directement l'tape 3.
2-B-2 - Reproduire le problme et trouver une solution

La deuxime tape consiste reproduire les conditions dans lesquelles les performances se dgradent. Cela
permettra de travailler beaucoup plus rapidement sur le problme, et parfois mme sans solliciter l'environnement
de production.
Une fois que les conditions dans lesquelles les performances ne sont pas bonnes sont identifies, il convient de
mettre en uvre et de tester les diffrentes solutions.
2-B-3 - Mise en production et mesure de l'impact

Deux lments perturbent la mesure exacte de l'optimisation apporte :
les diffrences 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 dgradent : il est parfois impossible ou trop coteux de
reproduire ces conditions. Par exemple, si les performances se dgradent lors d'un pic d'audience, reproduire
l'accs au service de nombreux utilisateurs simultanment 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 dmarche pralable a beaucoup d'importance. Elle permet de rduire le risque et de rduire le
temps ncessaire la mise en place des dispositifs d'optimisation.
2-C - tablir les premires pistes d'optimisation

2-C-1 - Ressources touches
Un projet est un assemblage de plusieurs ressources matrielles 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 dterminer quelle ressource est lie la dgradation des performances.
Parmi les ressources matrielles, il y a :
CPU ;
RAM ;
bande passante ;
disques durs.
Parmi les ressources logicielles, on peut citer :
nombre de fichiers ouverts ;

nombre de curs utiliss ;
nombre de connexions la base de donnes.
Afin d'tablir des pistes de solutions tudier, il convient de mesurer l'utilisation des diffrentes ressources cites cidessus afin de dterminer quelles sont celles qui sont exploites de manire 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 dcrits dans les paragraphes suivants.
NOTE : il ne faut pas croire que la libration de la ressource la plus sollicite permet
ncessairement d'amliorer de manire spectaculaire la performance de l'ensemble. Bien
souvent, produire une premire optimisation va conduire trouver qu'une autre ressource
est sature son tour. C'est pourquoi la dmarche est itrative.
Dans cette dmarche il faut respecter un certain ordre. Les ressources matrielles doivent
systmatiquement tre analyses avant les ressources logicielles (mais cela ne signifie
pas que les solutions sont ncessairement matrielles). Par exemple, il faut s'assurer que
l'utilisation du CPU par la base de donnes n'est pas critique avant de se pencher sur la
configuration du nombre de connexions la base de donnes.
BON SAVOIR : le disque dur doit tre analys aprs la RAM en raison du phnomne
de SWAP qui fait porter l'excdent de mmoire utilise par le disque dur lorsque la RAM
disponible est insuffisante.
2-C-2 - tablir les premires pistes d'optimisation - les outils serveur

Si vous savez quel moment prcis se produisent les problmes de performance, vous pouvez alors utiliser des
outils de mesure temps-rel . Ces outils sont pour la plupart utiliss en ligne de commande sous Linux.
2-C-2-A - Top
La commande TOP est l'outil de monitoring des systmes Linux par excellence. TOP produit une liste des processus
actifs du serveur, et dtaille leur consommation de temps processeur (CPU) et de mmoire (RAM). Il indique
galement la charge moyenne du systme sur trois priodes : 1 minute, 5 minutes et 15 minutes. Si cet outil ne
permet pas de connatre directement l'origine du problme, ce chiffre aide confirmer s'il s'agit d'un pic d'activit ou
bien si la machine est sature depuis un certain temps.
NOTE : il est noter que TOP a t pens de manire ne pas faire partie lui-mme des
processus le plus consommateurs de ressources qu'il mesure.
BON SAVOIR : TOP est un outil extrmement utile. Il permet d'identifier les problmes
les plus vidents sur la consommation de RAM et de CPU. En revanche, il est possible
que TOP ne dtecte aucun problme apparent, alors que votre machine est belle et bien
ralentie. Cela se produit notamment si le problme se situe au niveau des accs disque,
ou encore au niveau des ressources logicielles.
2-C-2-B - IOstat
La commande IOSTAT est utilise pour contrler la charge des priphriques entre/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 diffrents disques durs.
2-C-2-C - IOtop
Si l'accs en lecture/criture de votre disque est satur (par exemple trop de requtes INSERT, UPDATE ou DELETE
peuvent surcharger votre disque en criture), la commande TOP peut s'avrer insuffisante comme expos ci-dessus.
IOTOP prsente, de la mme manire que TOP, les processus qui consomment le plus de lecture et d'criture
sur votre systme.
2-C-2-D - Dstat
DSTAT est un outil de mesure transversal. Alors que TOP se spcialise dans l'activit CPU et IOTOP dans les accs
disques, DSTAT permet de surveiller l'activit sur le serveur de manire transverse. L'utilisateur peut dcider d'afficher
des indicateurs tels que l'activit CPU, l'activit des disques, l'activit rseau, etc. cte cte.
NOTE : ce n'est pas l'outil le plus prcis, mais il est trs pratique pour comparer
rapidement diffrentes mesures du systme. De plus, il permet aisment de raliser des
logs analysables sur un tableur comme Excel ou Open Office Calc.
2-C-3 - tablir les premires pistes d'optimisation - les outils client

2-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 lments tlchargs, la check-list des points courants optimiser, un rendu de la
page avec une image au bout de quelques secondes et des graphiques rsumant les lments rcuprs.
2-C-3-B - Firebug
Firebug est une plugin de Firefox apprci des dveloppeurs web. Il permet d'inspecter le code HTML en ciblant
directement l'lment dans la page, d'diter le style CSS pour tester le rsultat directement, dboguer le JavaScript
avec des points d'arrts 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 mme l'utiliser pour tester votre application en phase de dveloppement.
2-C-3-C - YSlow et Page Speed

YSlow et Page Speed sont des extensions de Firebug, respectivement dvelopp par Yahoo et Google, permettant
d'analyser les performances du trafic rseau 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 prs les mmes lments
une nuance prs. webpagetest.org permet de localiser (physiquement) d'o mane la
demande. En fonction de ce lieu, les diagrammes chronologiques peuvent varier.
2-C-4 - Les outils de monitoring

Si vous ne pouvez pas prvoir l'occurrence des problmes de performance, il sera plus simple de se servir d'outils
de monitoring afin de pouvoir accder l'historique des mesures de vos ressources.
2-C-4-A - Munin
Munin permet de surveiller les diffrentes ressources de vos serveurs. Un client est install sur chacune des
machines, et les donnes mesures sont agrges intervalle rgulier vers une machine centrale (o le serveur
Munin se trouve), et prsentes sous forme graphique.
Munin permet, dans son installation la plus simple, de surveiller l'utilisation du disque, de la RAM, du CPU et du
rseau. Cet outil est Open Source et il existe de nombreux plugins permettant de mesurer d'autres ressources, telles
que :
les temps de rponse (HTTP response time) ;

la consommation CPU pour une slection de processus (multimemory plugin) ;
taux d'utilisation des connections 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 problmes de performance lors de
pics de charge trs courts (de 5 15 minutes), Munin peut s'avrer insuffisant pour vous
apporter des informations suffisamment dtailles.
2-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 rponses dgrads...
- 10 Les sources prsentes sur cette pages sont libres de droits, et vous pouvez les utiliser votre convenance. Par contre la page de prsentation
Lorsqu'une alerte est remonte, l'outil peut tre paramtr pour prendre des actions, comme envoyer un mail d'alerte
aux administrateurs, ou encore envoyer des SMS.
NOTE : si les problmes de performance se produisent de manire alatoire et non
reproductible, Nagios peut tre utilis pour vous alerter des problmes rencontrs. Vous
pourrez alors vous connecter au serveur pour effectuer des mesures plus approfondies
en temps rel.
2-C-4-C - Autres outils

D'autres outils vous permettent de connatre l'activit de votre infrastructure. Par exemple, un outil de web analytics
permet de connatre approximativement le nombre de visiteurs sur votre plateforme.
D'autres outils (mergents) vous permettent d'avoir une vision encore plus prcise de votre activit. Par exemple
Collectd (http://collectd.org) permet de descendre sous la barre des 5 minutes impose par Munin.
2-C-5 - tablir les premires pistes en fonction des ressources

2-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 prcisment la ou les causes
de cette activit trop importante :
Apache/PHP : si votre problme se pose sur une page en particulier (sauf la page d'accueil o les problmes sont
souvent lis au nombre de connexions simultanes), il est utile d'analyser le code excut par celle-ci pour dceler
un potentiel dfaut. 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 intressant de mettre en place des mises en cache (ct serveur et ct client) ou
des traitements asynchrones afin de limiter l'engorgement lors d'un afflux trop important.
MySQL : une trs grande partie des problmes de performance lis la base de donnes peut tre rsolue en utilisant
les index adquats ou en mutualisant les requtes. Avant cela, il faut systmatiquement tablir une liste dtaillant
la fois la frquence de la requte (ou du type de requte) et le cot de cette requte.
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 problme sur un serveur de mail ou une base de
donnes full-text, etc., pourrait dclencher cette consommation CPU qui ralentirait votre serveur.
Si vous ne connaissez pas le nom du processus, n'hsitez pas vous aider d'une recherche sur Google pour en
apprendre plus. Et si vous tes persuads 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 accs SSH disponible depuis Internet avec des
mots de passes trop simples. N'oubliez pas qu'un hacker n'a pas besoin des accs root pour installer et excuter
ses programmes. Un simple accs utilisateur suffit. Il peut alors transformer votre machine en serveur de fichiers ou
bot, et les processus que vous voyez dans top sont coup sr nfastes. Tirez vue !
2-C-5-B - Bande passante

Pour obtenir une premire piste d'optimisation, vous devez rechercher le ou les lments qui consomment de la
bande passante. Par exemple, une page qui renvoie une vido de 100 Mo peut dgrader les performances de votre
site web si elle est appele de nombreuses fois.
Apache : la premire piste examiner sont les logs Apache afin d'observer combien consomme chaque requte 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 donnes envoyes chaque requte.
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 rseau, la raison d'un
affichage lent pourrait tre votre connexion internet, ou n'importe quel lment rseau
entre votre client et votre serveur.
2-C-5-C - Disque dur

Vos consommations de RAM et de CPU semblent normales et votre bande passante n'est pas sature. Il y a de
grandes chances que votre disque dur soit le facteur limitant. moins que votre application n'effectue un trs grand
nombre de lecture/criture sur le disque (ouverture et modification de fichiers, cration de documents, etc.), il est
probable que MySQL soit responsable. En effet, les requtes MySQL SELECT peuvent provoquer des accs disque
en lecture (si le rsultat de cette requte n'est pas en cache), et les autres types de requtes (INSERT, UPDATE,
DELETE) font systmatiquement des accs en criture.
2-C-5-D - Aucun de ces points ne semble critique ?

Le systme peut tre brid par ses ressources logicielles ou par des latences rseau.
Quelques pistes : nombre de threads MySQL, nombre de fichiers ouverts simultanment.
2-D - Reproduire le problme & tablir le diagnostic

2-D-1 - Reproduire les problmes de performance
Reproduire les conditions dans lesquelles les performances se dgradent est de plus en plus difficile au fur et
mesure que l'on effectue des optimisations. Or, savoir si l'on fait le bon scnario de test est presque aussi
important que de faire la bonne optimisation (celle qui nous permettra vraiment d'amliorer les performances sur
l'environnement de production). L'objectif est donc de simuler le fonctionnement de votre site web sur un seul des
aspect (base de donnes, accs disque etc.).
2-D-1-A - ab
ab est un outil d'valuation des performances de votre serveur web. Il indique le nombre de requtes par seconde
que votre application est capable de prendre en charge. Les deux paramtres principaux sont le nombre de requtes
simultanes ainsi que le nombre total de requtes effectuer.
BON SAVOIR : bien qu'il soit possible d'utiliser d'autres paramtres 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 plutt pour simuler l'arrive
massive d'utilisateurs sur une page. En effet, ab n'intgre pas de notion de scnario, car
il ne peut tester qu'une seule URL la fois.
2-D-1-B - JMeter
JMeter est une application que l'on peut dployer sur un poste de travail (il vaut mieux qu'il soit ddi afin que le
dveloppeur qui s'en sert puisse travailler pendant les runs de tests). C'est un outil qui permet de simuler un grand
nombre de requtes concurrentes HTTP et donc de simuler le comportement du site avec un grand nombre de
visiteurs. L'outil produit une synthse graphique des rsultats du test.
NOTE : dans le cas d'une architecture LAMP, l'outil ne prsente d'intrt que pour les
requtes HTTP. En revanche, il permet de tester beaucoup d'autres lments annexes
(serveurs de mails, connexion JDBC, etc.).
BON SAVOIR : JMeter n'mule pas compltement un navigateur (contrairement
un outil comme Selenium). Il est donc plus difficile de crer un jeu de tests qui soit
reprsentatif du comportement exact de l'application.
2-D-1-C - Selenium Grid (reproduction de scnario)

Selenium est une boite outils permettant de raliser des tests en simulant l'activit d'un ou de plusieurs utilisateurs
sur un site web. Grce un plugin Firefox, vous avez la possibilit d'enregistrer un scnario en naviguant sur le
site, puis de le rejouer volont, en vrifiant que l'affichage des pages est conforme aux attentes.
Selenium Grid vous permet de simuler une monte en charge de votre application en jouant plusieurs fois le mme
scnario en parallle. Si vous disposez de suffisamment de ressources, il vous sera possible de reproduire les
problmes de performance.
2-D-1-D - Batchs de requtes SQL

Obtenir la liste de toutes les requtes faites la base de donnes pendant l'excution d'un scnario reprsentatif,
puis le rejouer vous permettra de simuler l'impact de l'application sur la charge de votre serveur de donnes.
Pour faire cela, vous pouvez soit crire dans un journal les requtes au niveau de l'applicatif, soit configurer MySQL
pour tracer toutes les requtes (paramtre log de votre fichier my.ini ou my.cnf).
Vous avez la possibilit de rejouer ce batch de faon unitaire pour mesurer le gain de performance grce vos
optimisations, mais aussi de lancer plusieurs batchs en parallle pour simuler un pic activit.
2-D-2 - tablir le diagnostic

Comme expliqu auparavant, la solution est parfois vidente, il n'est parfois pas ncessaire de pousser plus loin
l'analyse de votre problme. En revanche, dans certains cas il faut prciser le diagnostic afin d'appliquer la correction
approprie.
Dans ce cas, il existe des outils et des dmarches simples permettant d'investiguer plus en profondeur sur l'utilisation
des ressources.
2-D-2-A - Logs Apache

SYMPTMES : votre site rpond correctement en temps normal, mais les temps de
rponse se dgradent sous la charge.
Les logs Apache tracent toutes les requtes faites au serveur Apache. En les configurant correctement, vous aurez
la possibilit d'obtenir le temps de rponse de votre site. En utilisant des outils de parsing appropris (AWStats,
Visitors, ou WebLog Expert), vous pourrez facilement visualiser le comportement de votre site en fonction du nombre
d'utilisateurs connects.
2-D-2-B - Logs MySQL (dont slow queries)

SYMPTMES : MySQL consomme normment de CPU ou le disque dur sature.
Les logs MySQL retracent l'activit de votre serveur de donnes. Le journal de log simple (celui configur par dfaut)
pourra vous renseigner sur la stabilit du serveur MySQL.
Le fichier de slow queries (il est parfois ncessaire de configurer ce log) liste l'ensemble des requtes dont la dure
d'excution est suprieure un seuil donn (lui aussi configurable).
Les requtes contenues dans ce fichier seront donc celles qui mobilisent le plus le serveur, et donc souvent celles
qui devront tre optimises.
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]
2-D-2-C - Analyse/parsing de code - Xdebug

SYMPTMES : PHP consomme normment de CPU.
La fonction Profiler de Xdebug est un outil qui permet d'analyser les temps d'excution de votre code PHP. Il permet
de savoir combien de temps est pass dans chacune des fonctions du code, et donc de dterminer quelle partie de
code est moins performante.
2-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 amliorer les performances et la stabilit de la base de donnes. Il produit un rapport
dtaillant :
les possibilits offertes par la configuration en cours ;

des mtriques telles que le nombre de jointures effectues sans index, hit ratio du cache, ... ;
des recommandations la fois sur la manire d'excuter les requtes, et sur les paramtres de configuration
modifier.
2-D-3 - Audit de la structure de la BDD

La structure de la base de donnes influence fortement ses performances. Ainsi, il faut s'assurer que vos tables
contiennent les index appropris, que les cls trangres sont en place.
Vrifiez aussi que les triggers ventuels ne nuisent pas aux performances : si chaque insert dans une table implique
l'excution d'un script complexe, il vaudra mieux mettre en place des batchs SQL asynchrones (quand c'est possible
bien sr).
BON SAVOIR : si les bonnes pratiques en matire de structure relationnelle des bases
de donnes recommandent le respect des normes (on parle de base de donnes norme),
la complexit de relation entre les diffrentes tables peut nuire aux performances. Il faut
toujours partir d'une base normalise, celle-ci tant bien plus facile maintenir. En cas de
problme de performance, on effectuera une dnormalisation au cas par cas.
2-D-3-A - Rseau interne/rseau externe

Si vous avez spar votre serveur applicatif et votre base de donnes, assurez-vous au pralable que votre bande
passante n'est pas consomme principalement en interne. En effet, si vous effectuez une grande quantit de requtes
ou des requtes avec des rsultats de taille importante, il est possible que ce soit la raison de la baisse des
performances en cas de forte affluence.
De manire gnrale, vous devez veiller envoyer le moins de donnes possible du serveur de base de donnes
vers l'application. crivez les requtes les plus slectives possibles et faites le maximum d'agrgations dans vos
requtes SQL.
3 - Amliorer la gestion de votre bande passante

Si vous disposez d'un site internet fort trafic ou d'un serveur avec une faible bande passante, vous pouvez apporter
des optimisations consistant rduire le flux qui transite entre le site et le navigateur du visiteur. Pour cela, il est
possible :
d'utiliser des systmes de cache ;

d'viter d'envoyer ou de dporter l'envoi de fichiers ;
ou encore de rduire la taille et le nombre des fichiers changs.
Prcision sur les diffrents temps d'attente :

Avant de commencer, il faut diffrencier deux types diffrents d'attente :
le temps de connexion ;
et le temps de latence.
Un navigateur internet doit recevoir l'ensemble du code HTML (DOM) du serveur avant de pouvoir afficher le contenu.
Pour chaque lment, contenu, image, vido, etc., le navigateur se connecte au serveur grce au protocole TCP/
IP. Ce processus prend en moyenne 70 ms pour un serveur proche et peut aller plus de 300 ms pour le rseau
mobile. C'est le temps de connexion.
cela, il faut ajouter le temps de latence du serveur qui ne rpondra pas toujours instantanment car il traite les
demandes dans l'ordre d'arrive.
Ces temps sont irrductibles. Aussi, les navigateurs rcents tablissent simultanment plusieurs connexions avec le
serveur. Ceci permet de parallliser les temps d'attente.
Sur une page HTML classique, 70% du temps d'affichage n'est pas le temps de tlchargement, mais le temps
ncessaire la connexion auquel s'ajoute le temps de latence, la meilleure des optimisations est donc de rduire
le nombre de requtes au serveur.
BON SAVOIR : il est possible, si vous avez une architecture comprenant plusieurs
serveurs, que les dialogues entre ces derniers impactent vos performances. Mme si ce
cas est trs peu probable, il est bon de s'en souvenir si vous ne trouvez pas d'o viennent
vos problmes de performance, notamment si les serveurs sont distants physiquement.
3-A - Systme de cache HTTP

Les systmes de cache permettent d'viter de recharger des lments dj tlchargs. Ceci permet d'avoir des
allers-retours serveur beaucoup plus rapides ou mme de les viter.
Les navigateurs des visiteurs grent leur propre cache. part quelques options configurables par l'utilisateur, le
fonctionnement de ce cache est dfini par les paramtres du serveur. L'intrt est de profiter du cache du navigateur
pour viter de rcuprer les fichiers et donc limiter la bande passante utilise par les navigateurs.
3-A-1 - Gestion des ETag

SYMPTMES : la bande passante de votre site est sature, ou le premier chargement
des pages est lent pour les visiteurs.
SOLUTION : par dfaut, la balise HTTP ETag (entity tag) est active, elle permet de ne pas tlcharger deux
fois les mmes fichiers. Chaque ressource statique (image, CSS, JS) possde un identifiant unique pour une date
de modification donne. Ainsi, lors d'un second chargement de la page, le navigateur enverra l'ETag au serveur
qui rpondra soit par un code 302 Found (trouv, donc non modifi) soit par un 200 OK (envoi du fichier). Ce
systme n'vite pas les allers-retours client-serveur, mais vite de renvoyer le contenu des fichiers, et donc vite la
consommation de bande passante ainsi que le traitement que doit effectuer le serveur.
Attention : si vous avez une architecture avec plusieurs serveurs, vous devez utiliser cette option avec prcaution.
Dans ce cas, l'ETag est diffrent pour chaque serveur. Il est possible que cette balise augmente la bande passante
plutt que de la rduire. C'est pourquoi certains outils de mesure vous conseillent de la dsactiver.
3-A-2 - Date d'expiration d'une ressource

SYMPTMES : malgr les ETags en place, le chargement d'une page reste lent. Vous
voyez dans Firebug qu'un grand nombre de fichiers est charg par page et que le temps
d'affichage de votre page est principalement du temps de latence.
SOLUTION : pour viter le temps de latence, il existe, pour le serveur Apache, le mod_expire. Il ajoute une en-tte
HTTP Expires qui indique la date d'expiration d'une ressource au navigateur. Tant que cette date n'est pas atteinte,
le navigateur utilisera directement les donnes qu'il a en cache. Il n'y a donc plus aucun temps d'attente.
La stratgie la plus efficace est donc de mettre une dure de vie illimite et de renommer la ressource lorsqu'elle
est modifie.
Exemple d'utilisation :
chaque modification d'un fichier, on en change le nom : style.1.0.css devient style.1.1.css. Il est aussi possible de
modifier l'URL d'appel en passant un paramtre fictif : style.css?c=1 devient style.css?c=2.
BON SAVOIR : ce procd est trs performant aprs le chargement de la premire page
qui ne peut bnficier du cache. De plus, il faut privilgier la rutilisation des ressources
dans les diffrentes pages. Par exemple : utiliser dans toutes les pages un mme et unique
fichier CSS.
3-B - Rduire le nombre des fichiers

SYMPTMES : vous voyez dans Firebug qu'un grand nombre de fichiers est charg par
page et que le temps d'affichage de votre page est principalement du temps de latence.
3-B-1 - Limiter le nombre de fichiers CSS et JS

Il est possible de regrouper les fichiers CSS ou JS en un seul. Plusieurs outils en ligne offrent ce service.
BON SAVOIR : cependant, si vous utilisez un framework ou un CMS, vrifiez que celuici ne propose pas un mode d'agrgation.
3-B-2 - Regrouper les images - Sprite

Il s'agit ici de regrouper les images du thme qui sont couramment utilises en une seule. Cette technique s'appelle
"Sprite". L'avantage est de n'utiliser qu'un nombre rduit d'images. En revanche, il faudra, via une feuille de style,
afficher l'image en background et la positionner.
NOTE : idalement une page de votre site sera compose :
1 feuille de style CSS ;

1 feuille de JavaScript JS ;
3 6 images pour le thme ;
les lments dynamiques et spcifiques de la page.
3-C - Rduire la taille des fichiers

SYMPTMES : la bande passante de votre site est sature, ou le premier chargement
des pages est lent pour les visiteurs.
3-C-1 - Rduire la taille des images

Si vous avez des images qui ne font pas partie intgrante du thme, vous devez les rduire au maximum, viter
de charger des images trop grandes (donc d'un poids important). Il est prfrable de les rduire ou d'utiliser des
mcanismes automatiques de mise l'chelle. Une image ne devrait jamais dpasser 500 ko (sauf exception).
BON SAVOIR : un outil en ligne permet de compresser un peu plus vos images sans
dtriorer la qualit. N'hsitez pas l'utiliser sur vos images avant de les mettre en ligne :
http://www.smushit.com/ysmush.it/
NOTE : vous trouverez facilement sur le web de nombreux articles traitant ce thme (GIF vs. PNG, PNG8 etc.).
3-C-2 - Limiter le poids des fichiers - Compression Gzip

Les fichiers HTML, CSS et JavaScript sont des fichiers texte et donc particulirement adapts une compression
ZIP importante. Le temps ncessaire cette dcompression est ngligeable pour le visiteur. En rduisant les flux
envoys aux utilisateurs, vous raliserez une conomie de bande passante.
BON SAVOIR : ce gain de bande passante s'effectue au dtriment d'une consommation
accrue de CPU (la compression utilise de la puissance serveur).
3-C-3 - Limiter le poids des fichiers - Minimify

Une autre possibilit pour limiter le poids de vos fichiers CSS et JavaScript est de les minimiser. La minimisation
supprime les retours la ligne, les tabulations ainsi que les commentaires. La lecture de ces fichiers devient donc
quasiment impossible, mais ce n'est pas un problme en production.
BON SAVOIR : la plupart des bibliothques JavaScript sont disponibles en version
"minimise". Elles sont donc plus rapides charger.
Par exemple, la version 1.4.4 min de jQuery pse 76.6 ko tandis que la version normale (de dveloppement) pse
178 ko.
3-D - Dporter des ressources

SYMPTMES : vous avez effectu toutes les modifications prcdentes, mais le temps
d'affichage de votre page est toujours long et l'augmentation de la bande passante de
votre serveur est impossible. Vous pouvez alors utiliser une solution multi-serveurs.
3-D-1 - Multi-sites
Dployer son site sur plusieurs noms de domaine (ou sous-domaines) permet l'utilisateur de charger plusieurs
fichiers simultanment sur plusieurs serveurs. En effet, le navigateur ouvre un nombre de connexion dfini par nom
de domaine. Ainsi avec 2 serveurs on ouvre 2 fois plus de connexion.
Le nombre de connexions simultanes ouvertes dpend de votre navigateur. Internet Explorer 6 n'ouvre que 2
connexions simultanes, l o Firefox 3 en ouvre 8.
Si votre page contient une vingtaine d'images/fichiers CSS/fichiers JavaScript, sous Internet Explorer 6, elles seront
rparties sur 2 connexions seulement, soit 10 ressources charges en srie et non en parallle.
En rpartissant les ressources sur 2 noms de domaine diffrents, il est possible que le navigateur ouvre jusqu' 4
connexions (ou 16 pour Firefox). Donc deux fois plus rapide pour charger la page.
Pour autant, il ne faut pas non plus tomber dans l'excs inverse en possdant un grand nombre de domaines. Tout
accs un nouveau domaine entrane des temps de recherche au serveur DNS (Domain Name System server,
Serveur de nom de domaine, temps de recherche du serveur). Que le serveur soit le mme ou non, ce temps sera
incompressible. De plus, le fait de multiplier les noms de domaine peut entraner une complexit de maintenance. Il
est donc important de calibrer le rapport nombre de ressources/nombre de domaines.
3-D-2 - Externaliser les ressources - CDN (Content Delivery Network)

Si la bande passante est sature, le CDN permet de stocker une page complte pour la restituer l'utilisateur le plus
rapidement possible sans passer par le serveur web. C'est une sorte de cache dport, donc qui ne charge pas le
serveur principal. Deux outils open source se dmarquent : Varnish & Squid.
Un service plus volu permet de golocaliser les destinataires : ce systme repose sur un mcanisme de routage
afin d'utiliser les serveurs les plus proches pour lui fournir les donnes de la page dont il a besoin. Akamai est
le leader du march.
NOTE : Google offre une sorte de CDN (en offrant une URL pour le tlchargement des
bibliothques JavaScript standard). Cette solution est un peu anecdotique.
3-D-3 - ESI (Edge Site Includes)

Norme maintenue par le consortium W3C. Elle permet de reconstituer une page web grce des balises dans la
page qui offrent la possibilit de charger la partie statique directement du serveur CDN, et la partie dynamique
du serveur web.
Exemple : si votre site possde une page o l'utilisateur sera identifi avec son nom, il vous est impossible de la
stocker dans le CDN car elle sera diffrente pour tous les utilisateurs. L'ESI permet d'identifier cette zone gnre
dynamiquement pour stocker l'ensemble du contenu de la page sauf le nom utilisateur. Ce dernier sera rcupr
directement du serveur web par le CDN qui l'agrgera dans la page envoye au client.
3-E - Dernires techniques

SYMPTMES : votre serveur rpond bien mais vous cherchez optimiser le temps
d'affichage de la page pour augmenter la ractivit du site perue par vos visiteurs.
3-E-1 - Chronologie de chargement

C'est une chose gnralement connue, mais dont les dtails et les implications ne sont pas toujours bien mesurs :
une page web est constitue de nombreux composants, qui sont chargs les uns aprs les autres par le navigateur.
Il faut s'assurer que la page peut tre consulte de manire confortable, mme si le temps de chargement est long.
L'ide est d'ordonner le tlchargement des lments en fonction de leur importance pour l'utilisateur. Par exemple,
les bibliothques JavaScript peuvent tre mises en bas de page.
NOTE : cette optimisation ne concerne pas directement les performances mais a un vrai
impact sur l'impression de vitesse pour l'utilisateur.
3-E-2 - Page Speed, module Apache

Google fournit un module Apache nomm Page Speed permettant d'acclrer la transaction serveur-client. Cet outil
permet d'appliquer un certain nombre de filtres sur les pages HTML, les fichiers CSS et JavaScript, les images PNG
et JPEG. Ces filtres permettent d'automatiser de nombreuses optimisations sans avoir parcourir l'ensemble du code
du projet. Les gains en performance peuvent tre trs importants sur certains sites.
BON SAVOIR : l'outil peut tre trs consommateur des ressources serveurs (processeur
et mmoire). Il est donc prfrable de faire trs attention en utilisant cette solution.
3-E-3 - Prcision sur les solutions prsentes

Il existe encore d'autres mthodes pour optimiser la gestion de votre bande passante comme ouvrir des connexions
persistantes, utiliser des balises meta HTML pour inclure des ressources directement dans le code HTML... Mais
celles-ci peuvent devenir rapidement compliques mettre en place. C'est pourquoi il faudra d'abord privilgier les
techniques proposes dans les autres parties avant de les prendre en considration.
4 - Rendre plus performant votre code PHP - JavaScript

4-A - Stocker les calculs en cache
SYMPTMES : votre serveur PHP ou MySQL est satur. Le processeur est utilis 100%,
ou dans le cas de la base MySQL, le disque sature.
4-A-1 - Envoi sans calcul - cache spcifique

Si les temps de calcul d'un lment de la page sont importants et que l'lment change peu, il est intressant de le
sauvegarder tel quel pour le restituer rapidement et soulager le processeur.
Par exemple, dans le cas de statistiques simples (nombre d'utilisateurs inscrits, etc.), il peut tre intressant de
stocker les statistiques en cache. Dans le cas de graphiques complexes, il peut tre intressant de stocker l'image,
gnre par le code PHP, pour une dure dtermine plutt que de r-effectuer les calculs pour chaque utilisateur.
4-A-2 - Memcache
Memcache est un systme de cache pour stocker les lments qui concernent la session des utilisateurs, des
rsultats de requtes etc. Il permet d'viter d'utiliser des ressources du serveur afin qu'il rponde plus rapidement.
Performant, il peut stocker n'importe quel objet PHP srialisable, et peut tre partag entre plusieurs serveurs dans
le cas d'une architecture avec load-balancing.
Vous pouvez utiliser Memcache pour stocker des rsultats de requtes SQL coteuses, des statistiques, etc.
4-B - Configuration PHP - Apache

SYMPTMES : les processus Apache/PHP utilisent la totalit des ressources processeur.
4-B-1 - APC - Cache PHP

Tout comme Memcache, APC (pour Alternative PHP Cache) est un systme de cache, mais la diffrence de
Memcache, APC est capable de mettre en cache les opcodes . Quand un script PHP est excut, il est d'abord
compil en interne par PHP. PHP ne stocke pas le rsultat compil du script et donc, la prochaine excution du
script, PHP le recompilera.
APC est conu pour stocker le rsultat compil dans son cache. Ainsi, lorsque PHP excute le script, APC lui servira
directement le script compil. PHP n'aura pas besoin de recompiler le script et conomisera donc beaucoup de temps.
La simple installation d'APC peut diviser la charge des processus Apache/PHP par 2 ou 3. N'hsitez donc
pas l'utiliser !
Vous pouvez galement utiliser APC comme un cache classique, mais la diffrence de Memcache, APC ne
fonctionne que sur un serveur.
Dans des environnements complexes, les deux existeront cte cte : APC pour mettre en cache les opcodes, et
Memcache pour mettre en cache les calculs / requtes.
4-B-2 - Autres paramtrages Apache - PHP

SYMPTMES : le nombre de connexions simultanes en pic est trs important. Les
processus Apache saturent, certains clients ne reoivent pas les pages web quand le trafic
est lev.
Apache permet de configurer le nombre de connexions simultanes qu'il peut ouvrir (c'est--dire le nombre de
requtes client auxquelles il peut rpondre simultanment).
Dans la plupart des installations, vous utiliserez les modules Worker ou Prefork. Les installations LAMP classiques
utilisent par dfaut le module Prefork, mais il faut savoir que d'autres solutions existent. De rputation, Prefork serait
plus stable et Worker plus scalable. Quoi qu'il en soit, chaque module MPM (Multi-Processing Modules), que ce soit
Prefork ou Worker, utilise des paramtres qu'il convient d'examiner car ils ne conviennent pas forcment des sites
ayant une forte frquentation. Ces paramtres peuvent brider votre application.
BON SAVOIR : dans le journal Apache, vous verrez facilement si le MaxClients est
atteint.
NOTE : il existe des alternatives au serveur web Apache. La plus connue est LightHTTPD.
Ce serveur web est rput plus performant. Mais avant de considrer cette option, sachez
que la communaut travaillant sous Apache est bien plus vaste, et que les gains en
performance ne sont pas toujours sensibles.
4-C - Limiter la consommation de RAM/CPU

4-C-1 - FileHandler et ResultSet
SYMPTMES : vos ressources RAM et CPU peuvent tre consommes par l'applicatif
(PHP) en temps de calcul, ou par la base de donnes. Dans le cas o vous avez
diagnostiqu qu'il s'agit d'une surconsommation de ces ressources par le processus
Apache (https), il sera ncessaire de passer en revue le code de l'application et sa
configuration.
PHP, comme JAVA ou la plupart des langages de programmation rcents gre automatiquement la libration des
ressources qui ne sont plus utilises (gre par le garbage collector). Nanmoins, les FileHandler et les ResultSet
doivent imprativement tre ferms de faon explicite, car ils ne sont pas pris en compte par le garbage collector.
Ainsi, si votre application effectue des lectures/critures sur des fichiers, n'oubliez pas que chaque pointeur de fichier
cr doit tre ferm :
PHP
$fh = fopen($filename, 'r');

while(!feof($fh)){
//...
}
fclose($fh);
D'autre part, si vous n'utilisez pas de framework ORM qui gre lui-mme la rcupration des donnes, veillez fermer
les ResultSets qui ont t ouverts :
PHP
$rSet = mysql_query("SELECT * FROM users");

while ($user = mysql_fetch_object($rSet)){
//...
}
mysql_freeresult($rSet);
4-C-2 - Autoload
SYMPTMES : la consommation processeur de vos processus PHP est trop leve.
Cette fonctionnalit permet de trouver une classe si elle n'a pas t identifie dans le contexte courant. Ainsi, votre
code PHP peut charger les classes PHP dont il a besoin la vole . Par exemple, l'objet $user, de la classe User,
ne peut tre instanci si le fichier User.class.php n'a pas t inclus ( require_once ).
Exemple :
PHP
/* Dfinir une manire de trouver la classe User */

function custom_autoload($className){
require_once
dirname(__FILE__) . "/classes/" .$className . ".class.php";
}
/*
* Ajouter la fonction custom_autoload la liste
PHP
* des fonctions permettant de trouver une classe.

*/
spl_autoload_register('custom_autoload');
/* Sans autoload, cette instanciation aurait gnr une Erreur:
* Fatal error: Class 'User' not found in ...
*/
$user = new User();
Cet exemple semble trivial, mais imaginez que vous disposez d'une librairie de classes que vous utilisez partout dans
votre application. Par dfaut, deux options sont envisages :
inclure la vole les classes que vous utilisez chaque fois, ce qui devient vite fastidieux ;
faire l'inclusion de tous les fichiers au dbut du script, mais vous incluez alors des fichiers qui ne sont pas
utiliss dans tous les scripts, d'o une consommation inutile de RAM et de temps processeur.
Utiliser l'autoload est donc fortement recommand, et cette solution est mme plus efficace que celle qui consiste
inclure les fichiers la vole, car un require_once doit vrifier si ce fichier a t dj inclus ou non.
4-D - Dporter l'excution du code

SYMPTMES : la consommation processeur de vos processus PHP est trop leve ou le
temps de rponse des pages est trop long, mme sous une charge normale.
4-D-1 - Mettre en place des traitements asynchrones

La conception la plus intuitive et la plus simple d'un projet est souvent pense en synchrone. Nanmoins, la mise
en place de processus asynchrones permet la fois de diminuer le temps d'attente de l'utilisateur, et de lisser les
pics de charge.
Pensez notamment externaliser les tches suivantes :
production de rapport, mise jour de statistiques ;

envois de mails ;
appels de services externes.
4-D-2 - Ajax
L'Ajax (Asynchronous JavaScript And XML) est une manire de dialoguer avec le serveur aprs le chargement de
la page, grce au JavaScript. L'intrt est de charger les lments qui prennent du temps aprs que le navigateur
de l'utilisateur a affich le contenu de la page internet.
Si vous avez un calcul long, que vous devez faire chaque fois et que malgr toutes les recommandations que vous
avez suivies, vous ne pouvez pas rduire le temps, alors il est prfrable d'afficher la page sans cet lment puis
de rcuprer le rsultat sur le serveur ensuite.
Toutefois, il faut faire attention car certains moteurs de recherche ne pourront pas indexer le contenu de ce bloc.
NOTE : ATTENTION AUX FRAMEWORKS. Certains frameworks et certains CMS doivent
charger un ensemble de modules et d'outils avant de passer l'excution du code
effectif . Dans la mesure du possible, lorsque vous faites de l'Ajax, essayez de charger
le moins d'lments possible pour limiter la dure d'excution et ainsi acclrer le retour
d'information.
NOTE : requtes multiples. Si une page effectue plusieurs appels Ajax, sachez que PHP
ne pourra traiter la requte suivante qu'une fois que la session aura t libre (fonction
session_write_close). En effet, la session tant par dfaut libre en fin d'excution du
script, les requtes Ajax pourront alors tre traites simultanment.
4-E - viter les fausses optimisations

LE CONTEXTE : votre serveur PHP sature. Vous vous tournez vers votre dveloppeur, qui vous explique qu'il a LA
solution, il faut absolument changer tous les guillemets doubles par des guillemets simples parce que ceux-ci sont
plus rapides.
Mfiez-vous absolument de ces fausses optimisations !
Le web regorge de mythes. Comment les reconnatre ?
Gnralement, il s'agit d'un conseil sur une manire de coder bas niveau .
Quelques exemples :
les boucles for qui dcrmentent la variable au lien de l'incrmenter sont plus rapides ;
la boucle for est plus rapide que la boucle while ;
il faut utiliser des guillemets simples au lieu de guillemets doubles ;
le dveloppement objet est plus lent que le dveloppement procdural.
Tous ces conseils rsultent de dbats sans fin entre dveloppeurs de langages de programmation.
Vous trouverez sur Internet des benchmark foison comparant les performances entre guillemets simples et
guillemets doubles. Et il est vrai que lors d'une boucle qui concatne 100000 fois une chane de caractres, les
guillemets simples sont 3% plus rapides que les guillemets doubles. Mais restons focalis sur l'important ! Si vous
lisez ce livre blanc, vous n'tes pas la recherche d'une amlioration de 3% de vos performances, mais bien de
100 ou 200%. Oubliez donc ces fausses optimisations, et concentrez-vous sur de vraies solutions comme l'tude
des index ou l'optimisation des flux !
5 - Optimiser votre base de donnes MySQL

Les principales solutions d'optimisation consistent rduire les cots de lecture des tables MySQL. Trois types de
solutions sont possibles :
optimiser la gestion des index ;

agrger des donnes ;
amliorer les requtes.
5-A - Gestion des index

5-A-1 - Indexation de la BDD
Les symptmes : votre application se comporte bien lorsque la base de donnes est vide. Mais lorsque la base
de donnes se remplit avec des volumtries de production, l'application ralentit. La base de donnes consomme la
plupart des ressources du systme : la consommation CPU ou les accs disques atteignent 100%. Les logs MySQL
slow queries montrent que certaines requtes SELECT sont lentes excuter.
La solution :en termes de base de donnes, la premire solution examiner est de vrifier que les index sont bien
dfinis.
Qu'est-ce qu'un index ?

Imaginons un bibliothcaire devant rechercher un livre parmi une collection. Si ces livres sont empils dans le
dsordre, il va devoir parcourir sa collection livre par livre pour trouver le livre qui l'intresse. De la mme manire,
dans une base de donnes, si une table livre contient un million d'enregistrements et que l'on cherche un livre par
son nom , le moteur de la base de donnes devoir parcourir un un tous les enregistrements. Le bibliothcaire
va bien sr classer les ouvrages. Une fois classs, il sera capable de retrouver un livre trs rapidement, par simple
dichotomie. En termes de bases de donnes, ce classement s'appelle un index . Si la colonne nom est indexe,
la base de donnes pourra retrouver un ouvrage par son nom sans parcourir l'intgralit de la table.
De la mme manire que le bibliothcaire va passer d'une journe de recherche quelques minutes, la base de
donnes passera de quelques secondes de recherches quelques millisecondes. Et l'efficacit des index augmente
avec la taille de la base !
L'avantage des bases de donnes par rapport aux classements physiques est de permettre plusieurs tris la fois.
On peut crer un index sur le nom, sur l'auteur, et sur le numro ISBN la fois.
Cot d'un index : bien sr, lorsqu'un nouveau livre arrive, il faut l'indexer. Ainsi, si les index permettent de gagner en
temps de recherche, ils ralentissent lgrement l'insertion des donnes. Un index occupe aussi de la place sur le
disque dur. Cependant, dans une application web typique, les donnes sont lues bien plus souvent qu'elles ne sont
crites. De manire quasi systmatique, le gain de performance apport par un index dpasse largement son cot.
Analyser les requtes : lorsque l'on cre un index sur une base de donnes, il est important de tracer les amliorations
que l'index apporte sur le temps d'excution de la requte. Le plus souvent, l'amlioration est flagrante (on passe
de plusieurs secondes quelques millisecondes).
BON SAVOIR : si l'amlioration n'est pas flagrante, il faut vrifier que l'index est bien
utilis. Pour cela, on utilisera la commande ANALYZE TABLE de MySQL :
La lecture des analyses n'est pas aise, mais c'est un des meilleurs moyens de comprendre le fonctionnement de la
base de donnes. Dans ce rapport, vous devez vous assurer qu'il n'y a plus de full-scan sur les tables. Les fullscan correspondent un parcours de tous les enregistrements sans utiliser d'index.
Indexer les colonnes des requtes les plus frquentes/les plus complexes : les logs de slow queries MySQL
devraient mettre en vidence les requtes les plus lentes. Analysez ces requtes et vrifiez notamment la partie
WHERE et ORDER BY de la requte. Les colonnes utilises devraient tre indexes. Vrifiez galement si
votre requte effectue une jointure entre plusieurs tables, car les clefs trangres devraient tre indexes.
L'option log_queries_not_using_indexes permet d'ajouter aux logs de slow queries toutes les requtes qui
effectuent un full-scan . Elles pourront ainsi tre rapidement repres.
BON SAVOIR : si vous utilisezdes tablesInnoDB, nous vous recommandons vivement
de dclarer toutes les clefs trangres. Une clef trangre dclare dans InnoDB doit
forcment tre indexe. Ainsi, vous ne pourrez pas oublier l'index et vous viterez un
futur problme de performances. Vous pouvez consulter ce sujet l'article sur les clefs
trangres de la documentation MySQL.
5-A-2 - Les index multi-colonnes

Si votre requte SQL optimiser contient plusieurs colonnes dans la clause WHERE, crer un index sur chacune des
colonnes ne sera pas optimal. La base de donnes utilisera en effet un des index, mais ne peut pas utiliser plusieurs
index sur la mme table simultanment. La base de donnes va alors chercher utiliser l'index le plus efficace (le
plus discriminant). Pour ces cas, il est possible d'utiliser des index multi-colonnes.
En reprenant l'exemple de la bibliothque, on pourrait crer un index sur les auteurs, puis les noms d'ouvrage. Les
livres seraient d'abord classs par auteurs, puis par nom d'ouvrage. Ainsi, il serait rapide de retrouver un livre dont
on connat l'auteur et le nom.
BON SAVOIR : dans les index multi-colonnes, l'ordre des colonnes est primordial.
5-A-3 - Cardinalit des index

Il peut se produire des cas o la base de donnes dispose de la possibilit d'utiliser plusieurs index pour une mme
requte et doit faire le choix entre deux index utiliser. Elle prendra alors gnralement l'index le plus discriminant,
c'est--dire l'index qui dispose du plus grand nombre de valeurs diffrentes pour une mme colonne. On parle de
cardinalit de l'index.
Par exemple, si notre table d'ouvrage possde une colonne auteur qui contient le nom de l'auteur, et une colonne
type qui contient soit livre , soit magazine , la cardinalit de l'index type sera de 2, alors que la cardinalit
de l'index auteur sera gale au nombre d'auteurs.
Si une base de donnes a le choix entre les deux index, elle prendra l'index auteur chaque fois.
La cardinalit est estime par la base de donnes au fur et mesure des oprations. Pour les tables MyISAM, si
on effectue un trs grand nombre d'oprations de suppression/insertion, la cardinalit d'un index peut tre fausse.
La base MySQL prendra alors le mauvais index ce qui peut nuire aux performances. La commande ANALYZE
TABLE reffectue le calcul de cardinalit pour corriger ce problme. Attention cependant, cette commande bloque
la table le temps de son excution. Il ne faut donc surtout pas l'excuter pendant un pic de charge !
5-A-4 - Recherche de contenus text : index FULLTEXT

Dans le reste de ce paragraphe ddi aux index, nous allons cependant aborder un type particulier d'index : les
index FULL-TEXT.
Reprenons l'exemple de notre bibliothcaire. Il vient de classer tous les ouvrages par ordre alphabtique. Quelqu'un
arrive, et lui demande de retrouver un ouvrage dont il ne se souvient pas compltement du titre. Il se rappelle
cependant que le titre finit par de la mthode .
Notre bibliothcaire est bien embt. Son classement alphabtique fonctionne, condition que l'on connaisse le
dbut de nom du livre, pas la fin. Il ne va pas avoir d'autre choix que de parcourir sa collection de livre entire. De la
mme manire, un index classique sur la colonne nom ne pourra pas tre utilis sur une requte du type :
SQL
SELECT * FROM books WHERE name LIKE '%de la mthode'
Si ce type de requte vous pose des problmes de performances, il faudra crer un index FULL-TEXT. Les index
FULL-TEXT permettent de rechercher rapidement du texte plac au milieu ou la fin d'une colonne.
BON SAVOIR : sous MySQL, il y a cependant des restrictions. Les bases de donnes
InnoDB ne supportent pas les index FULL-TEXT. Il faudra utiliser le moteur MyISAM, qui
possde lui-mme d'autres limitations.
5-A-5 - Moteur full-text spcialis (Lucene, Apache Solr)

Vous avez appliqu toutes les optimisations ci-dessus, vous avez cr des index de manire optimale, et malgr
cela, vos requtes sont toujours lentes.
Dans le cas de notre table livres , il s'agirait d'un client souhaitant retrouver un livre dont le contenu contienne
le mot collier , mais aussi le mot girafe . Le mcanisme devrait tre suffisamment souple pour permettre les
fautes d'orthographe (par exemple giraffe au lieu de girafe ), et ne retourner que les livres publis aprs 2009.
Dans ce type d'exemple, il faut envisager de revoir l'architecture de l'application. De toute vidence, MySQL n'est
pas bien adapt aux recherches FULL-TEXT complexes, et est incapable de raliser des requtes approximatives
(fuzzy-searches).
Si vous souhaitez raliser des recherches de ce type, et si vous avez des problmes de performance cause de ces
requtes, il existe des bases de donnes spcialises pour la recherche dans une grande quantit de documents
full-text .
Lucene : Lucene est un moteur de recherche full-text. l'origine implment en Java, il en existe une implmentation
PHP dans le Zend Framework : http://framework.zend.com/manual/fr/zend.search.lucene.html
Lucene stocke des documents et permet de rechercher en full-text dans le document ou ses mtadonnes. Il
permet d'effectuer des fuzzy-searches et des requtes complexes.
L'implmentation PHP de Lucene est relativement lente par rapport son homologue Java. Aussi, Lucene ne devrait
pas tre utilis si la volumtrie est trop grande. On se tournera alors vers Solr.
Apache Solr :serveur bas sur la version Java de Lucene. Il s'interroge via web-services (sur un modle REST), et
permet facilement de stocker les documents puis de les chercher. Si vos problmes de performances sont dus
une fonctionnalit de recherche full-text et que l'implmentation de Lucene dans le Zend Framework ne suffit plus,
Apache Solr est la solution dont vous avez besoin :http://lucene.apache.org/solr/
NOTE : nous avons prsent Lucene et Apache Solr, qui sont les solutions les plus
connues, mais il en existe d'autres. NOTE : sans ce paragraphe, nous n'avons que
prsent les possibilits d'optimisation les plus lmentaires. Bien matriser la gestion des
index de la base de donnes est primordial pour obtenir des performances satisfaisantes
mais le sujet est vaste et dpasse le cadre de ce livre blanc. Il faudrait par exemple traiter
des diffrents types d'index (HASH, TREE, etc..). N'hsitez pas approfondir le sujet avec
la documentation MySQL :
5-B - Agrgation
La bonne gestion des index a une importance directe sur les performances de votre projet web. Mais il est possible
de rencontrer malgr tout des problmes lis au temps d'excution de certaines requtes. C'est notamment le cas
des applications qui prsentent des statistiques.
Agrger des donnes permet de faire des requtes sur les tables moins volumineuses. Le principe est d'appliquer
un ensemble de pr-calcul sur la table puis de stocker le rsultat dans une nouvelle table. Les donnes seront prises
dans la table agrge. Le but est de n'avoir que trs peu de calcul faire au moment de l'excution de la requte
afin d'amliorer le temps de rponse.
5-B-1 - Agrgation en batch

L'une des techniques parmi les plus simples mettre en uvre pour agrger des donnes consiste crer un script
(PHP ou autre) qui s'excute rgulirement pour effectuer des pr-calculs (batch).
Ce script devra tre lanc via une tache automatique. Le temps entre deux excutions est critique. En effet, il y a
plusieurs rponses pour un mme problme :
excuter trs souvent le script : ceci permet d'avoir des donnes proches du temps rel, et peut tre excut
rapidement, condition que la base de donnes s'y prte. Il est possible que la requte la plus simple mette
plusieurs minutes, auquel cas il sera impossible de lancer souvent le script sous peine de saturer le serveur ;
excuter une fois par jour : mme si le script est long, il ne bloquera pas le serveur. Il est conseill de
l'excuter au moment o la charge serveur est la plus faible (souvent en pleine nuit).
Avantage : la solution est souvent facile dvelopper et dployer, grande libert dans le code.
Inconvnient : les donnes prsentes ne sont pas le reflet exact de la production. Selon les volumes, les tests sont
parfois longs et complexes raliser.
5-B-2 - Agrgation directe (triggers)

Le trigger permet de crer l'agrgation directement en base de donnes. chaque nouvel enregistrement dans une
table, il est possible de crer un trigger qui effectuera le pr-calcul et l'enregistrera directement dans la table agrge.
Il faut cependant faire attention la limite des bases de donnes.
Avantage : temps rel.
Inconvnient : maintenance, migration de base de donnes et limites en criture.
Exemple : chaque insert dans la table principale, vous ajoutez trois lignes dans la table d'agrgation. Ainsi au lieu de
faire un insert, il y en aura quatre. La base saturera donc beaucoup plus rapidement s'il y a de nombreuses critures.
5-C - Optimisation des requtes la base de donnes

5-C-1 - Rduire le nombre de requtes
SYMPTMES : votre application effectue pour chaque page un grand nombre de requtes
que vous voyez dans les logs MySQL (plusieurs centaines). Les pages sont longues
s'afficher bien que ni le serveur PHP, ni le serveur MySQL ne soient saturs.
Si votre application effectue un trop grand nombre de requtes, la base de donnes peut tre la raison des mauvaises
performances. En effet, en dehors du temps d'excution de la requte, il faut compter le temps de latence la base
de donnes. Or, ce temps de latence n'est pas ngligeable, car il est parfois plus important que le temps d'excution
de la requte elle-mme ! De manire gnrale, il faut donc prfrer une requte importante plutt que plusieurs
petites requtes afin de factoriser le temps de latence.
Par exemple :
PHP
$result = mysql_query("SELECT * FROM users");

while ($user = db_fetch_object($result)){
$countResult = mysql_query("SELECT count(1)
FROM cars
WHERE user_id = $user->id");
// ...
}
Ce script excutera une premire requte pour rcuprer tous les utilisateurs, puis, pour chaque utilisateur retourn,
une nouvelle requte sera effectue pour connatre le nombre de voitures qu'il possde. Une meilleure pratique
consiste lancer une seule requte pour tout rcuprer en une seule fois :
PHP
$result = mysql_query("
PHP
SELECT u.*, count(c.id)

FROM users u JOIN cars c ON u.id=c.user_id
GROUP BY u.id");
while ($user = db_fetch_object($result)){
// ...
}
5-C-2 - Optimiser les requtes les plus critiques

SYMPTMES : votre serveur MySQL est satur.
Pour optimiser les appels la base de donnes, on est souvent tent de traiter en priorit les requtes les plus
longues tre excutes.
En ralit, si une requte met 10 secondes s'excuter, mais qu'elle est peu appele, l'optimisation n'amliorera pas
les performances de l'application. Il faut plutt s'intresser aux requtes qui consomment le plus de temps sur un
intervalle de temps reprsentatif d'une utilisation normale de l'application.
Une solution pour savoir quelles sont les requtes qui doivent tre optimises est d'identifier l'ensemble des requtes
excutes sur une priode reprsentative (la mise en place du log des slow queries avec un seuil 0 permet de les
voir toutes), puis d'analyser le rsultat en comptant le nombre d'occurrences des diffrentes requtes (au paramtre
prs). En pondrant ensuite le temps d'excution par le nombre d'appels de chaque requte, vous obtiendrez un
classement des requtes les plus coteuses.
5-C-3 - viter les requtes imbriques

SYMPTMES : votre serveur MySQL est satur.
L'excution de requtes imbriques implique la cration d'une table temporaire. Si elle peut tre vite (ce n'est pas
toujours le cas), il vaut mieux effectuer des jointures.
Exemple :
SQL
SELECT *
FROM users
WHERE user.role_id IN (
SELECT uid FROM users_roles
WHERE rid IN (
SELECT rid
FROM role
WHERE name IN ('administrateur', 'client')
)
)
Cette requte utilise deux requtes imbriques, alors que l'usage de jointures serait plus performant :
SQL
SELECT *
FROM users u
JOIN users_roles ur on ur.user_id = u.id
JOIN role r on r.id=ur.role_id
WHERE r.name IN ('administrateur', 'client')
5-D - Dnormalisation du modle de donnes

Un bon modle de donnes doit tre facile maintenir. Pour cela, une donne ne doit tre prsente qu' un endroit
dans la base. On dit alors que la base est sous sa forme normale .
Imaginons une base de donnes contenant des produits achets et des utilisateurs. La table liant les produits aux
utilisateurs sera sous sa forme normale si elle contient une clef trangre vers les tables des utilisateurs et des
produits :
Utilisateurs
Id
Name
1
John
2
bob
Achats
User_id
1
2
Id
1
2
Produits
Product_id
2
1
Name
TV
Radio
Si l'on souhaite obtenir la liste des achats, on effectuera une requte avec probablement deux jointures pour rcuprer
le nom des utilisateurs et des produits.
La forme dnormalise serait :
Utilisateurs
Id
Name
1
John
2
bob
Achats
User
John
Bob
Id
1
2
Produits
Product
Radio
TV
Name
TV
Radio
Cette forme sera plus efficace requter, puisque la base de donnes n'aura pas de jointures faire.
En revanche, sous cette forme, la base de donnes est beaucoup plus dure maintenir. Si un produit change de
nom par exemple, il faudra modifier son nom dans tous les champs dnormaliss de la base, ce qui est complexe,
et aussi long !
Bonne pratique : il vaut mieux toujours partir d'un modle normalis et ne dnormaliser que lorsque les problmes de
performance sont constats. En effet, la dnormalisation complexifie la maintenance du code et devrait tre vite
si possible.
La dnormalisation sera par contre la rgle pour accder des techniques plus avances comme les bases
de donnes multidimensionnelles. Dans ce cas, on devra en effet commencer construire une vue entirement
dnormalise de la base avant de remplir la base de donnes multidimensionnelle.
NOTE : d'autres bases de donnes comme les bases de donnes NoSQL reposent sur
des modles moins stricts et moins norms (donc plus dnormaliss). Nous n'aborderons
cependant pas le sujet dans ce livre blanc, le sujet mritant lui seul son propre livre !
5-E - Base de donnes multidimensionnelle

L'agrgation de donnes dans des tables d'agrgats permet d'offrir des statistiques rapidement. Cependant, cette
approche peut tre limite si les statistiques produire sont trs diverses.
Prenons l'exemple classique suivant : vous disposez de plusieurs magasins dans le monde. Chacune des ventes
est logge dans une table qui contient le produit vendu, le prix, le vendeur, la date, le magasin avec sa localisation
gographique. partir de cette table, vous crez une table d'agrgat pour connatre le nombre de ventes par vendeur.
Puis vous souhaitez crer un nouvel indicateur (donc une nouvelle table d'agrgat) pour connatre les ventes par
magasin. Deux mois plus tard, nouvel indicateur : les ventes par magasin, par catgorie de produit et par mois... Au
bout de quelques mois, votre base de donnes est encombre de tables d'agrgats difficiles maintenir.
Pour ces cas ou vous ne pouvez savoir priori quelles sont les statistiques que vous souhaitez produire, les bases de
donnes multidimensionnelles sont la solution. Une base de donnes multidimensionnelle, ou base OLAP (On-Line
Analytical Processing), permet d'analyser un grand nombre de donnes sous des axes diffrents. Dans le cas de notre
magasin, la base de donnes multidimensionnelle effectuera l'intgralit des agrgats possibles en une passe (ce
que l'on appelle calculer le cube multidimensionnel). On pourra alors interroger la base instantanment sous toutes
ses dimensions (c'est--dire sous tous les axes d'agrgation possibles). Si vous tes habitus de Excel, vous pouvez
voir une table multidimensionnelle comme un tableau crois dynamique pouvant contenir des milliards de lignes.
Maintenir une base multidimensionnelle demande cependant des efforts. Il faut mettre en place un script de
chargement de la base partir de votre base relationnelle (MySQL).
En rsum, utilisez une base de donnes multidimensionnelle si :
vous avez des problmes de performance sur un affichage de statistiques ;

ces problmes de statistiques sont dus la volumtrie de vos donnes ;
vous ne savez pas priori quelles statistiques seront ncessaires ou si la diversit des statistiques empche
l'utilisation de tables d'agrgats.
Si vous dcidez d'utiliser une base de donnes multidimensionnelle, vous devrez choisir la base utiliser. Citons
les plus connues :
Mondrian : une base de donnes multidimensionnelle open-source ;

Microsoft Analysis Services : la base de donnes multidimensionnelle de Microsoft ;
Essbase : la base de donnes multidimensionnelle d'Oracle ;
SAS OLAP Server : le serveur de base de donnes multidimensionnelle fournit par la suite SAS d'analyse BI.
5-F - Configuration MySQL

Votre site web n'effectue plus que des requtes indexes. Vous avez prcalcul toutes vos statistiques. Bref, vous
avez puis toutes les optimisations recommandes dans ce document, et vous avez encore un problme de
performances.
Alors, et seulement ce moment, vous pouvez regarder les paramtres d'optimisation de MySQL.
MySQL est une base proposant plusieurs moteurs de gestion des tables en son sein, les plus connus tant MyISAM
et InnoDB. Chacun de ces moteurs possde des performances et des paramtres d'optimisation qui lui est propre.
5-F-1 - MyISAM vs InnoDB

Le choix entre MyISAM et InnoDB n'est pas anodin. La plupart du temps, le choix est dict par les fonctionnalits de
la base. Par exemple, seul InnoDB permet de dclarer des contraintes d'intgrit sur la base de donnes. InnoDB
dispose aussi d'un journal qui garantit que les donnes seront toujours dans un tat stable, mme si le serveur de
base de donnes s'arrte en plein milieu d'une opration d'criture.
contrario, MyISAM est le seul proposer un index full-text. Si vous avez besoin de cette fonctionnalit, le choix
sera donc impos directement.
Vous avez bien sr la possibilit de mlanger les moteurs, chaque table pouvant utiliser un moteur qui lui est propre.
Cette solution est utiliser avec prcaution. En effet, chaque moteur dispose de ses propres restrictions, notamment
en termes de backup. En utilisant les deux moteurs, vous cumulez les deux limitations.
En termes de performance, chaque moteur possde ses caractristiques propres. Si vous avez choisi MyISAM ou
InnoDB pour l'une des fonctionnalits qui lui est propre, mieux vaut rester votre choix initial que dcider de changer
pour un problme de performances. Si, par contre, votre choix a t effectu parce que c'est le moteur par dfaut ,
vous pouvez alors lgitimement vous poser la question d'un changement de moteur.
InnoDB semble tre le moteur prfr de la plupart des dveloppeurs. D'un point de vue des performances
uniquement, il se diffrencie sur deux grands points : il dispose d'un journal, et il supporte le row-levellocking .
Pour une base de donnes, un journal est un espace dans lequel la base va crire toutes les actions d'criture
effectues. Dans la pratique, cela signifie que les actions sont crites deux fois. Bien sr, d'un point de vue des
performances, cela a un cot puisque les donnes sont crit en double. Cependant, c'est la seule manire de
permettre de grer des transactions (d'effectuer des rollbacks ), et surtout, cela garantit de toujours pouvoir
rcuprer la base de donnes dans un tat stable, quelles que soient les coupures du serveur.
Le fait que MyISAM ne dispose pas de journal ne le rend cependant pas systmatiquement plus performant. En effet,
lors d'une opration d'criture en base avec MyISAM, ce dernier bloque toute la table. contrario, InnoDB ne bloque
que les lignes (le fameux row-level locking).
Ainsi, InnoDB est plus efficace que MyISAM pour les applications haute concurrence d'accs (typiquement
une application web).
InnoDB possde cependant des limitations qu'il est bon de connatre. La plus connue tant la rcupration du compte
de lignes dans une table qui effectue un parcours de table complet (trs lent). Il faut donc viter les requtes du type :
SQL
SELECT COUNT(*) FROM books
Enfin, InnoDB est activement dvelopp alors que MyISAM est plus stable. On peut donc s'attendre voir de
nombreuses amliorations de performance arriver sur InnoDB.
InnoDB tant un systme plus complet que MyISAM, il dispose galement de plus de paramtres. Alors que MyISAM
est assez facile configurer, InnoDB demandera plus de temps pour obtenir un systme optimal.
La liste de tous les paramtres InnoDB est prsente sur cette page :
http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html
Mme si cette liste est longue, si vous souhaitez faire du fine-tuning MySQL, nous vous conseillons de la parcourir
en entier, certains paramtres ayant des impacts sur d'autres.
Nous ne parcourons pas l'intgralit des paramtres dans ce livre blanc (ce n'est pas le sujet), mais allons prsenter
les principaux.
5-F-2 - Taille du cache InnoDB

Le paramtre principal influenant les performances MySQL sera bien sr la taille du cache. Plus le cache est grand,
moins MySQL devra aller chercher de donnes sur le disque lors de requtes, et donc plus la base sera rapide.
Sous InnoDB, la taille du cache est gre par le paramtre innodb_buffer_pool_size. Par dfaut, il est initialis
128 Mo. Sur un serveur de base de donnes ddi, on peut monter jusqu' 80% de la RAM du serveur. Attention
cependant, MySQL aura besoin de RAM galement pour stocker le programme, la structure de la base, etc. De plus,
si vous utilisez MyISAM en parallle d'InnoDB, il faudra galement laisser de la place en RAM pour le cache MyISAM !
5-F-3 - Nombre de connexions simultanes

Le nombre de connexions simultanes la base est limit par le paramtre max_connections.
Si le nombre de connexions maximal est atteint, la base de donnes retournera une erreur (Toomany connections).
Il est donc trs important que ce paramtre ne soit pas trop bas. Chaque thread PHP pouvant ouvrir une connexion
la base de donnes, le nombre de connexions maximum demandes la base de donnes devrait tre environ gal
au nombre de threads PHP autoriss dans Apache (voir ce sujet la section Autres paramtrages Apache-PHP).
Note : la commande SHOW STATUS MySQL permet de voir le nombre maximal de connections simultanes
ouvertes sur le serveur, ce qui permet de voir en production si on se rapproche ou non du maximum autoris.
Attention : ne modifiez pas le paramtre max_connections sans modifier le paramtre table_cache qui lui est
associ. table_cache reprsente le nombre de fichiers ouverts simultanment par MySQL. En MyISAM, pour chaque
connexion, lorsque MySQL accde une table, MySQL ouvre un fichier. Si MySQL fait une requte avec un join sur
2 tables, il ouvre 2 fichiers, etc...
Dans l'idal, on devrait donc avoir table_cache = max_connections * nombre de join maximum.
Dans le cas d'InnoDB, ce nombre peut tre diffrent puisque selon la configuration d'InnoDB, celui-ci crit toutes les
tables dans le mme fichier, ou crit une table par fichier (suivant la valeur du paramtre innodb_file_per_table).
5-F-4 - Nombre de threads

SYMPTMES : vous disposez d'un serveur trs puissant (plus de 8 coeurs). MySQL ne
sature pas le CPU, mais celui-ci plafonne 20% ou 40% de la puissance maximum. Les
autres ressources (disque/RAM) ne saturent pas non plus. Le serveur semble ne pas
donner tout son potentiel.
Par dfaut, MySQL n'ouvre pas plus de 8 threads pour InnoDB.
Le paramtre rgissant ce comportement est innodb_thread_concurrency : http://dev.mysql.com/doc/refman/5.0/
en/innodb-parameters.html#sysvar_innodb_thread_concurrency
Si vous disposez d'un serveur ddi puissant (par exemple avec 24 processeurs), vous pourriez vouloir adapter ce
paramtre.
La recommandation MySQL est de configurer ce paramtre deux fois le nombre de processeurs + le nombre
de disques .
Nous vous recommandons cependant d'effectuer des tests avec des valeurs trs diffrentes pour voir le
comportement de votre application. En effet, en augmentant le nombre de threads, vous augmentez la concurrence
et donc le risque de locks.
5-F-5 - Log file

SYMPTMES : le disque dur de votre serveur MySQL sature en criture cause d'un
grand nombre de commandes INSERT/UPDATE/DELETE.
Lorsqu'on utilise InnoDB, MySQL crit un journal. Comme expliqu prcdemment, l'ide du journal est d'crire
l'ancien tat de la base avant de l'craser avec le nouvel tat. En cas de crash, on peut ainsi toujours revenir en
arrire. L'criture sur le disque est effectue en double. Ceci est inhrent toutes les bases de donnes respectant
les normes ACID (Atomicit, Cohrence, Isolement, Durabilit), c'est dire quasiment toutes les bases SQL sauf
MySQL en mode MyISAM. Il existe dans MySQL des paramtres permettant d'assouplir l'criture dans le journal
(par exemple de faire l'criture une fois par seconde plutt qu' chaque UPDATE ou INSERT). Le paramtre
innodb_flush_log_at_trx_commit rgit ce fonctionnement :
http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit
http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
6 - Rationaliser votre infrastructure
Lorsque la mise en place d'une des solutions prcdentes est coteuse, il est intressant d'examiner l'architecture
physique de la solution.
Les solutions associes l'infrastructure matrielle sont nombreuses et la plupart consistent augmenter le nombre
de serveurs.
Cette partie prsente quels sont les moyens d'amliorer les performances de votre application grce l'augmentation
des capacits matrielles.
6-A - Upgrade
Le principe de l'upgrade des serveurs est simple. Il s'agit d'augmenter de faon constante les performances physiques
de sa machine : ajouter de la RAM, augmenter la taille des disques ou ajouter des disques, augmenter la puissance
du ou des processeurs, utiliser un systme multi-curs .
Ces actions permettent d'augmenter les capacits du serveur pour accueillir un plus grand nombre de connexions
utilisateurs et/ou de calculs serveur. Une fois upgrad, le serveur web sera capable d'absorber une plus grande
charge.
BON SAVOIR : augmenter la puissance d'un serveur cote relativement peu tant
qu'on reste dans une puissance standard , mais le rapport cot/performance crot
exponentiellement ds que l'on sort de la norme.
Il est prfrable de rapidement s'orienter vers des solutions de clustering qui fournissent une architecture plus robuste
notamment en cas de panne. Aussi, il est intressant de dfinir un seuil partir duquel il convient de stopper l'upgrade,
pour dmarrer une stratgie de clustering.
6-B - Clustering
6-B-1 - Sparer Apache - MySQL
Pour beaucoup d'applications PHP-MySQL, l'accs aux donnes reprsente un point majeur de l'utilisation des
ressources serveurs (goulet d'tranglement). Or, dans le mme temps, l'application a un besoin non ngligeable
de ressources pour faire fonctionner l'application PHP. Dans de nombreux cas, ces deux demandes de ressources
simultanes peuvent crer des lenteurs, voire des dfaillances.
Une solution pour rsoudre ce problme est de sparer le serveur Apache, contenant l'application PHP, du serveur
MySQL contenant le Systme de Gestion de Base de Donnes (SGBD). Ainsi, les actions effectues sur l'un des
serveurs n'impacteront pas l'autre et les performances en seront amliores. Le SGBD tant dans de nombreux cas
le goulet d'tranglement d'un site web, il sera ici trait de faon ddie par un unique serveur qui n'aura que cette
charge grer.
BON SAVOIR : dans ce cas, la latence augmente. L'application ne doit pas effectuer
de trop nombreuses requtes par page.
6-B-2 - Load-balancing des serveurs Apache
Le load-balancing Apache permet de distribuer le trafic sur plusieurs serveurs. L'objectif est de multiplier le nombre de
serveurs capables d'hberger le site cible et ainsi de partager la charge relative aux actions utilisateurs sur plusieurs
serveurs.
La distribution sera effectue par un serveur ddi (le load-balancer). Pour les sites trs fort trafic, on aura recours
un botier physique (propos par les hbergeurs) afin de rediriger les accs au site web sur les diffrents serveurs. Un
paramtrage fin est galement ncessaire pour partager les donnes en cache, ainsi que les donnes sessions (APC,
Memcache). La base de donnes doit galement tre partage pour tre accessible des diffrents serveurs web.
BON SAVOIR :en plus d'amliorer les performances (plusieurs serveurs rpondent en
mme temps aux requtes utilisateurs), il y a une autre raison pour mettre en place cette
optimisation : la solution est beaucoup plus robuste. En effet, comme plusieurs serveurs
fonctionnent en parallle, si l'un d'entre eux est dfaillant, les autres sont susceptibles
de prendre le relais instantanment. En revanche, cela demande un suivi constant de
l'activit des serveurs en utilisant Nagios par exemple. Dans le cas contraire, un serveur
peut devenir indisponible sans toutefois alerter l'administrateur du site.
Note :la maintenance de la solution devient plus complexe du fait que les modifications effectues sur un serveur
doivent tre diffuses vers tous les autres.
6-B-3 - SQL Master/Slave
Dans la plupart des cas d'utilisation d'un serveur MySQL, les requtes effectues sont des requtes de lecture, de
rcupration de listes de produits, d'informations personnelles. Ces demandes frquentes surchargent les serveurs
MySQL qui doivent grer par ailleurs les requtes d'insertion (INSERT) et de mise jour (UPDATE).
Une nouvelle solution d'optimisation d'architecture matrielle est de ddier diffrents serveurs MySQL des actions
prcises. Un serveur matre gre alors toutes les requtes d'INSERT et d'UPDATE, et un serveur esclave gre toutes
les requtes de slection. Ainsi, la charge du SGBD sera partage entre plusieurs serveurs. Pour conserver une
cohrence de donnes, le serveur esclave est rpliqu du serveur matre en temps rel.
BON SAVOIR :une solution qui n'amliore pas les performances mais qui augmente la
robustesse de la solution est le SQL Clustering. Le principe est de mettre disposition
un nouveau serveur SQL si le principal n'est plus disponible (crash, maintenance, etc.).
Cette architecture est base sur une rplication automatique des donnes du Systme de
Gestion de Base de Donnes. Le serveur courant est alors utilis pour grer l'ensemble
des actions du serveur web, pendant que le serveur de backup ne fait que recopier les
actions effectues sur le principal. L'avantage est que ce systme peut tre coupl une
utilisation des instances master/slave.
6-C - Cloud Computing
Pour simplifier, le Cloud Computing peut tre dfini comme le moyen d'excuter des tches de calcul en parallle
sur diffrents serveurs Ce qui est intressant dans le cadre de l'amlioration des performances, c'est la faon d'utiliser
cette puissance de calcul dynamiquement, en fonction de la charge serveur.
Il est trs frquent qu'un site Internet soit soumis des pics d'activit ; de ce fait, il n'est pas forcment ncessaire de
possder une structure matrielle maximale pendant les priodes d'activit faible, ou moindre, de votre site internet.
Le principe volutif du Cloud Computing , comme le propose Amazon (AWS - EC2), est de mettre disposition
de l'application une force de calcul supplmentaire (image de votre site web) quand vous en avez besoin. Ce besoin
trs spcifique peut tre dfini de diffrentes faons : l'utilisation du CPU du serveur, la charge mmoire du serveur
ou toutes autres donnes relative l'utilisation et la charge du serveur web. Toutes ces donnes peuvent tre
surveilles afin de dclencher l'utilisation de nouvelles ressources matrielles. Ainsi, votre infrastructure s'adaptera
automatiquement votre besoin.
BON SAVOIR : ce mouvement s'accompagne des bases de donnes NoSQL. Ces
bases de donnes sont moins simples requter mais elles se dupliquent facilement. En
fait, ces besoins sont tirs par les gants du Web (Google, Amazon, ...) qui ont besoin de
rechercher des informations qui ne sont pas ncessairement structures.
7 - Utilisation - Reproduction - Remerciements

Amliorez les performances de vos projets web de The Coding Machine est mis disposition selon les termes de
la licence Creative Commons Paternit - Pas d'Utilisation Commerciale - Partage l'Identique 2.0 France.
Nous remercions particulirement _Max_ et kdmbella pour leur relecture attentive et efficace de ce livre blanc,
Les autorisations au-del du champ de cette licence peuvent tre obtenues http://www.thecodingmachine.com/
fr/contact.

Livre Blanc Performance Web

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Livre Blanc Performance Web

Hochgeladen von

Copyright:

Verfügbare Formate

Dmarche de diagnostic et d'optimisation pour

amliorer les performances d'un site Web.

3-D-2 - Externaliser les ressources - CDN (Content Delivery Network).........................................................18

1-B - De l'importance de mettre en place un plan d'amlioration continu des performances

1-C - qui s'adresse ce livre blanc et comment l'utiliser ?

1-D - Pourquoi ce livre blanc ?

1-E - propos de The Coding Machine et des auteurs

2 - Introduction, dmarche et diagnostic

Descartes, discours de la mthode.

2-B - Vue d'ensemble de la dmarche

2-B-1 - Constater le problme de performance

applicatif (Apache PHP) ;

2-B-2 - Reproduire le problme et trouver une solution

2-B-3 - Mise en production et mesure de l'impact

2-C - tablir les premires pistes d'optimisation

Parmi les ressources logicielles, on peut citer :

nombre de fichiers ouverts ;

2-C-2 - tablir les premires pistes d'optimisation - les outils serveur

2-C-3 - tablir les premires pistes d'optimisation - les outils client

2-C-3-C - YSlow et Page Speed

2-C-4 - Les outils de monitoring

les temps de rponse (HTTP response time) ;

activit CPU trop importante ;

2-C-4-C - Autres outils

2-C-5 - tablir les premires pistes en fonction des ressources

2-C-5-B - Bande passante

2-C-5-C - Disque dur

2-C-5-D - Aucun de ces points ne semble critique ?

2-D - Reproduire le problme & tablir le diagnostic

2-D-1-C - Selenium Grid (reproduction de scnario)

2-D-1-D - Batchs de requtes SQL

2-D-2 - tablir le diagnostic

2-D-2-A - Logs Apache

2-D-2-B - Logs MySQL (dont slow queries)

2-D-2-C - Analyse/parsing de code - Xdebug

les possibilits offertes par la configuration en cours ;

2-D-3 - Audit de la structure de la BDD

2-D-3-A - Rseau interne/rseau externe

3 - Amliorer la gestion de votre bande passante

d'utiliser des systmes de cache ;

Prcision sur les diffrents temps d'attente :

3-A - Systme de cache HTTP

3-A-1 - Gestion des ETag

3-A-2 - Date d'expiration d'une ressource

3-B - Rduire le nombre des fichiers

3-B-1 - Limiter le nombre de fichiers CSS et JS

3-B-2 - Regrouper les images - Sprite

1 feuille de style CSS ;

3-C - Rduire la taille des fichiers

3-C-1 - Rduire la taille des images

3-C-2 - Limiter le poids des fichiers - Compression Gzip

3-C-3 - Limiter le poids des fichiers - Minimify

3-D - Dporter des ressources

3-D-2 - Externaliser les ressources - CDN (Content Delivery Network)

3-D-3 - ESI (Edge Site Includes)

3-E - Dernires techniques

3-E-1 - Chronologie de chargement

3-E-2 - Page Speed, module Apache

3-E-3 - Prcision sur les solutions prsentes

4 - Rendre plus performant votre code PHP - JavaScript

4-A-1 - Envoi sans calcul - cache spcifique

4-B - Configuration PHP - Apache

4-B-1 - APC - Cache PHP

4-B-2 - Autres paramtrages Apache - PHP