La performance d’un site est vitale pour ses ventes ou sa consultation, deux géants célèbres ont fait des études sur ce point : Google et Amazon. Le premier a déterminer que si sa latence augmentait de 0,5s, il perdait 20% de son trafic et le second a déterminer qu’en répondant en 100 ms de plus, il perdait 1% de CA !
Il est très complexe de dimensionner les serveurs nécessaires et ajuster les paramètres systèmes afin d’être sûr d’obtenir une navigation agréable pour un grand nombre d’utilisateurs. L’empirisme commence à bien fonctionner avec le recul de plusieurs sites hébergés mais je pense qu’on peut faire mieux et commencer à structurer des calculs plus scientifiques.
Je vous ai parlé des différents processeurs du marché et des infrastructures blades. Aujourd’hui quand un client me demande un hébergement, je dois partir de ce qui existe pour m’assurer des performances que je peux lui offrir : son site. Il est optimisé ou pas, on le voit vite, si les caches bloc/eav ont bien été activés dans le code, si les requêtes en bases sont bien conçues, si les fichiers CSS/AJX sont regroupés, etc… On sait que l’optimisation du site a été pensée (et réalisée) ou pas.
Partons du principe que le code a été optimisé et qu’on cherche maintenant juste à dimensionner. Plusieurs outils vont nous servir : les logs d’apache (ou du reverse proxy si il y a un load balancing), les logs des tests Opensta et les informations fournies par Google Analytics.
Analytics fournit une information qualifiée et permet de faire quelques projections. Le problème c’est que toutes les pages ne sont pas forcément taggées, elles ne sont pas forcément les mêmes entre l’ancien et le nouveau site et enfin seules les pages consultées sont prises en compte, les webservices, ajax, les transferts de fichiers plus ou moins volumineux et les autres facteurs ne sont pas pris en compte. Donc seul les pages php générées (ou rproxysées) seront prises en compte mais ca constitue déjà un premier indice sur la charge que porte le CPU. Dans analytics :
- Dans le tableau de bord, prenez une période d’un jour de haute charge du site. (Un seul jour de sélectionné dans la période)
- Cliquez sur visiteurs, puis visiteurs-tendances puis sur visites
- Cliquez sur l’icone « Graphique horaire » à droite, juste au dessus du premier graphique
- Prenez la tranche d’une heure qui contient le plus de visites et gardez le nombre au chaud
- Allez ensuite dans nombre de pages vues, pour la même tranche horaire, prenez le chiffre
- Allez enfin dans temps passé sur le site et prenez, toujours pour la même tranche horaire le temps moyen
Ensuite, avec la formule (((temps de visite moyen en seconde)*(nombre de visiteur horaire))/3600) / ((temps de visite moyen en seconde)/(nombre de pages par visiteurs), vous savez le nombre de pages que les serveurs doivent générer par secondes. Certains sites charges toujours les mêmes pages, d’autres ont des catalogues tellement profonds que les chaines de cache ne vont quasiment pas travailler.
Pour compléter l’analyse, faites des sessions Opensta, SQL Analyzer et regardez précisément le nombre de fichiers chargés, générés et le temps que le(s) serveur(s) met à répondre, par session. Jouez plusieurs profils différents, des vrais séances de surf pour que ce soit réaliste. (20 profils différents semblent raisonnablement précis) Une fois les profils fait, jouez en N en même temps, jusqu’à ce que le temps de réponse du site se mette à augmenter légèrement.
Vous avez alors trouvé, sur votre architecture de test, le nombre de personnes connectées simultanément.
Sur un site qui génère 20 000 visites par exemple, le nombre de sessions simultanées peut, en réalité, être assez faible avec des pics à 600 sessions simultanées « seulement ». Les sites étant tous différents dans leurs comportement, une seule méthode compte, simuler précisément, confronter à l’historique réel du site contenu dans analytics et extrapoler ces simulations du serveur de tests à la plateforme finale. Si vos simulations montrent un ralentissement après 150 sessions simultanées et que vous devez atteindre 600, il vous faudra 5 serveurs (4 + 1 autre fournissant les 20% de sureté).
On prépare un Guide de l’optimisation Magento qui sera articulé comme suit (à priori) :
1°) Introduction
2°) Infrastructure
3°) Système d’exploitation
4°) environnement LAMP
5°) Architecture/conception du code Magento
6°) Développement
7°) Optimisation (SQL&Code analyzer)
8°) Tests de charges / Benchmarking
9°) Les caches (memcached, rproxy, eav/zend)
10°) Nice things, hints & tricks
Comme mon équipe n’est pas spécialisée dans le développement, je pense que les chapitres 5/6 seront réalisés par des volontaires. De toute façon, tout cela se passera dans le Wiki.
janvier 25th, 2010 at 18 h 06 min
On peut simplifier ta formule par :
(nombre de visiteur horaire * nombre de pages par visiteurs)/3600
C’est plus simple quand même.
janvier 26th, 2010 at 17 h 13 min
C’est vrai
Ceci dit, l’article date pas mal. Actuellement avec les versions de Magento qui ont évolué et les machines qui gagnent en perf plus Zend serveur, un bon site, sur un gros serveur, ca peut monter à 25 000 visiteurs uniques par jour en moyenne. Je devrais mettre pas mal d’articles à jour sur les volumétries et les perfs. Mais de toute façon je « dois » à la communauté un article sur l’optimisation et l’installation d’un serveur Web dédié Magento, ca demande beaucoup de rédactionnel mais j’y intégrerai des tests.