juil 27

Magento sur le grill!

S’il est désormais acquis pour tous (ou presque) que Magento offre toute la richesse fonctionnelle requise pour des sites e-commerce professionnels exigeants, il existait peu d’études approfondies sur sa capacité à accompagner les projets les plus ambitieux en termes de volumétrie, et nous étions fréquemment interrogés sur cette question.  Magento peut-il  gérer un catalogue de plusieurs millions d’articles ?  Une fréquentation de plus de 20 millions de visites par mois mois ?   Plusieurs milliers de commandes à l’heure ?

La réponse à cette question dépend évidemment d’un certain nombre de paramètres pas forcément liés directement à la qualité intrinsèque de Magento (qualité des développements, infrastructure d’hébergement etc…) Toutefois, si l’on part du postulat que toutes les bonnes pratiques sont respectées à tous les niveaux, qu’est réellement capable de faire Magento?

Pour y répondre de manière factuelle, nous avons mené sur plusieurs semaines, une grande campagne de tests de charge, mobilisant jusqu’à une douzaine de serveurs octo-cœurs, déroulant des scénarios complets et représentatifs d’un trafic réel, sur plusieurs jours de charge.

Nous avons compilé ces résultats et procédé à quelques analyses présentées dans un document téléchargeable ici : http://factory.clients.smile.fr/docs/magento-performances_et_scalabilite.pdf

Quelques mots sur la démarche

L’infrastructure et les scénarios de tests mis en œuvre ont pour objectif de mesurer plusieurs indicateurs :

  • les temps de réponse des principaux écrans de navigation dans un contexte de très forte charge
  • la capacité de service nominale d’un serveur et la scalabilité d’une architecture multi-serveurs
  • le trafic supportée en fonction du nombre de frontaux
  • le nombre de commandes et de mise au panier par heure en fonction du nombre de frontaux
  • l’endurance de la plateforme sur une période de surcharge de 8h consécutives

Le document présente l’ensemble de l’architecture mise en oeuvre ainsi que les adaptations apportées à Magento pour pouvoir supporter de telles charges.

Alors, ça donne quoi?

En synthèse, la plateforme Magento a présenté un bon comportement en charge et une excellente extensibilité.

Les temps de réponse unitaires sont excellents pour les pages qui utilisent pleinement le dispositif de cache, et sont plus élevés pour les pages de mise au panier ou de confirmation de commande. Un aspect important des choix d’architecture logicielle de Magento est de solliciter principalement la CPU des frontaux, et assez peu la base de données.   C’est cette caractéristique qui permet une très bonne extensibilité, c’est-à-dire la capacité à mettre en place une plateforme à très haute capacité d’accueil par simple ajout de serveurs.   Cette extensibilité permet de faire monter en puissance une plateforme au fur et à mesure que son succès se confirme, sans rupture ni grande migration.

Cette campagne de tests démontre qu’une plateforme Magento bien conçue peut accueillir 28 millions de visites par mois, en servant jusqu’à 800 pages par seconde aux heures de pointe.

Scalabilité de Magento

La base de données quant à elle, arrive à servir 20 serveurs frontaux en conservant une charge acceptable. Au delà, il faudra commencer à réfléchir à d’autres pistes d’optimisation.

Ce qu’il faut retenir

Notons, pour fixer les idées, que ces 28 millions de visites / mois, associées à une hypothèse de taux de transformation de 2% correspondent, pour un panier moyen de 20 €, à un CA mensuel de 22 M€, et pour un panier moyen de 100 €, à un CA mensuel de 112 M€.   Il y a peu d’acteurs dans le monde dans cette catégorie.

Indicateur Valeur
Nombre d’articles dans le catalogue 1 050 000
Capacité d’un unique frontal Magento en visites / mois 1 525 200
Capacité de 10 frontaux Magento en visites / mois 14 136 000
Capacité de 10 frontaux Magento en commandes / heure 1 080
Nombre maximum de frontaux pour une base de données 20
Capacité maxi d’une plateforme Magento sur une base de données unique, en visites / mois 28 millions

—————-

Conclusion

Beaucoup de chemin a été fait depuis les premières versions de Magento qui souffraient, il faut bien le reconnaître, de quelques soucis de performances. Aujourd’hui, la donne a changé et Magento n’a définitivement pas à rougir face aux mastodontes du e-commerce sur cette question de la scalabilité et des performances. Et ce que l’on sait aujourd’hui de Magento 2 qui nous arrivera l’année prochaine nous laisse espérer des résultats encore meilleurs…

écrit par Frédéric de Gombert \\ tags: , , ,

jan 23

Après plusieurs mois de travail, on peut commencer à en parler car Nitrogento va enfin voir le jour !

Depuis trois ans, NBS System s’est spécialisé dans l’hébergement de Magento, WordPress et Drupal, cela m’a donné l’occasion de faire de nombreuses conférences, pendant les Bargento notamment, sur la performance et l’optimisation. Ce blog en est d’ailleurs le reflet, j’y ai souvent distillé des conseils sur ces sujets.

Mais nous avons voulu aller plus loin en mettant sur le marché une extension qui boost les performances de Magento. Les points clefs sont connus mais cela nécessitait beaucoup de travail. Voici donc un avant goût de Nitrogento, de son contenu et de ses performances.

Voici les quelques questions qui se posent probablement à la lecture de ces lignes :

Qui

J’ai commandité (par NBS System) la création d’une extension Magento auprès de L’academy et de l’Agence DnD.

Les deux maîtres codeurs derrière ce petit bijou sont essentiellement Matthieu Bouchot (Academy) et Aymeric Aitamer (Agence DnD). J’ai conçu le cahier des charges et demandé les fonctionnalités, la réalisation des caches (FPC / Bloc / Custom Bloc) a été faite par Matthieu, les CDN /Minify/Sprite et l’admin en Back office par Aymeric.

Ce sont des experts dans le domaine Magento et de vieux complices en matière de performances, j’ai notamment un peu co-écrit avec Aymeric sur ce blog et on aime beaucoup faire la course à l’optimisation tous les deux.

Quand

Tout est quasi finit en terme de développement, nous en sommes à la phase de beta test depuis quelques jours. Une fois celle-ci terminée on attaquera la phase de benchmark et la mise sur le marché se fera aux alentours de mi-février, tout début Mars au plus tard si on tombait sur un pépin.

Quand au « Quand cela a commencé » : depuis quelques mois, environ 6.

Sur le Web of course :)

Julien et Christophe (de DnD, aidé par notre illustrateur Flash de talent, Yoann Dondicol) m’ont monter le site Magento qui sera en ligne prochainement pour vendre l’extension sur www.nitrogento.com. (ouverture mi février normalement). Je pense qu’on le mettra peut être aussi dans Magento Connect. Les partenaires NBS System pourront aussi l’acheter directement auprès de leur interlocuteur habituel.

Pourquoi

Parce que Magento est flexible et puissant mais il est également assez lent et consommateur de ressources. Parce qu’un magasin rapide vend plus et offre une meilleure expérience à l’utilisateur.

Les chiffres et statistiques sont là :

  • Akamai & Forrester : 5 secondes de temps de chargement : 20% des personnes partent
  • Shopzilla a augmenté ses revenus de ~10% en chargeant en 2s au lieu de 7s
  • Yahoo perd 5 à 9% de trafic en chargent avec 400 ms de plus
  • Google : +500 ms, -20% trafic
  • Amazon : +100 ms, -1% de ventes
  • Les utilisateurs interrogés disent que 2 secondes c’est acceptable, 4s c’est trop
  • 52% des visiteurs considère que la vitesse de chargement d’un site est un critère essentiel pour revenir
  • En 2010, 75% des visiteurs ne reviennent pas si le site est lent (contre 64% in 2006) }
  • La vitesse influe directement sur votre SEO ET votre SEM
  • Google a divisé le web en deux clans (voir webmaster tools->labo->performances) : les sites rapides, qui chargent en moins de 1,5 secondes et les lents, qui chargent en plus de 1,5 secondes…

etc, etc, etc… Le web fourmille d’étude en ce sens, la vitesse joue sur tout, y compris massivement sur le taux de transformation, bien que là je n’ai pas retrouvé l’étude qui m’intéressait dans l’immédiat.

Quoi

Eh oui, ca reste le plus important en fait, ça fait quoi Nitrogento ?

Vous l’aurez voulu, on est partit :

  1. Full Page Cache pour la version CE et plus efficace (et moins buggé) que celui de la EE
  2. Bloc caching (y compris si les développeurs ont oublié de l’instancier)
  3. Custom Bloc Caching (cache des blocs non natifs à Magento)
  4. Auto Sprite : génération automatique du sprite lié au template pour diminuer le nombre de requêtes
  5. Déploiement automatique en CDN (pour paralléliser les downloads des ressources statiques)
  6. Concaténation des JS et CSS en un seul fichier
  7. Minify et compression de : HTML / JS / CSS
  8. Paramétrage depuis le backoffice des Expire headers, Etags et compression Gzip

Voila, j’ai oublié une ou deux choses involontairement, une ou deux de plus qui sont encore en gestation pour notre roadmap de la version 1.1.

Au final on atteint quoi ?

Pour le moment, ce sont des statistiques temporaires, le temps de finaliser les benchmarks réels :

  • -0,5 seconde en moyenne sur le temps de chargement des pages
  • ~8 fois moins de charge serveur sur la home (FPC)
  • ~2 fois moins de charge serveur sur les pages internes (bloc cache+custom bloc cache)
  • ~2 fois moins de requêtes HTTP (Sprite)
  • chargement des ressources statiques 2 à 3 fois plus rapides (CDN)
  • grade A/A sur Gtmetrix.com (98 en Yslow et 96 en Pagespeed) au lieu de C/C (78% Yslow / 76% pagespeed)
  • avec un serveur de base, on arrive à 1,9 seconde au lieu de 3,1 pour la home
  • avec un serveur optimisé pour Magento, on arrive sous la barre des 0,7 seconde pour la home
  • économie de ~15% de bande passage (sprite + minify + gzip)
  • pour un visiteur qui revient sur une page ou repasse sur la home, on atteint un temps de chargement qui en général est sous la barre des 0,4 secondes et moins de 20 Ko

Coté Serveur :

  • En période « normale », ça accélère le chargement
  • En période de pic (soldes, mailings, ventes privées) ça diminue considérablement la charge des serveurs et la bande passante utilisée

Coté Navigateur :

  • Ça accélère le rapatriement des données statiques (Minify + Gzip + CDN)
  • Ça optimise le cache du navigateur (ETags+Expire headers)
  • Ça diminue le temps d’affichage des pages

On peut vérifier ?

Oui, le Nitrogento store sera équipé aussi d’un demostore et d’un « Nitrostore » (un démostore sous Nitrogento) , sur la même machine, ce qui permettra à tout le monde de voir la performance, de tester et de vérifier avec GTmetrix, Pagespeed et /ou Yslow.

Vous pouvez aussi vous porter volontaire pour la phase de Beta, si vous êtes retenu, l’extension sera alors gratuite pour votre site une fois qu’elle sera commercialisée.

Voici déjà un shoot, pris pendant l’intégration :

L’image est un peu petite, mais la note du Yslow est bien à 98%…

Les limites

Pour être honnête, il faut aussi parler de  ce que le produit ne fait pas ou ne peut pas faire.

Par exemple, quand on est authentifié ou qu’on a un bloc contenant des informations de session, de panier ou d’authentification, le FPC (Full Page Cache) se désactive, ce qui est normal et indispensable.

Ensuite, la mise en cache des custom blocs nécessite d’appeler un helper pour être prise en compte dans le back office et donc visible pour activation / désactivation. Rien de compliquer à faire mais ce n’était pas automatisable.

Pour le moment seul le CDN accessible en CNAME par FTP est géré. Dans la v1.1, un support natif du CDN de NBS, de celui d’Akamaï et de MaxCDN devrait être intégré.

Enfin, pour le moment, nous avons pris le partit de le mettre en Anglais car la très grande majorité du marché est anglophone et que les intégrateurs Français parlent presque tous anglais.

Combien

500 $ par an pour un serveur frontal.

Si vous avez plusieurs serveurs frontaux, il faut avoir l’extension sur chacun d’entres eux mais les suivants seront facturés 100$ par an. Ce tarif intègre également les mises à jour et les évolutions.

(Les clients et partenaires NBS System profiterons d’une tarifications spéciale)

écrit par Philippe Humeau \\ tags: , , , , ,