Ah la fraicheur des matins de ventes de fin d’année…

Quand les E-commerçants vivent leur grands moments, le gros des ventes, leur croissance…
Tout y est pour que la tension soit à son maximum ! En cas de bug, c’est le grand moment de solitude. Oh pas pour tous, loin de là mais parmi 1000 sites, il y en a toujours un ou deux qui vont connaitre des soucis.

Cette année, il a été sauvé in extremis par un de nos administrateurs, qui a trouvé un comportement assez improbable de Magento. Cela pouvant arriver à tout le monde, il est souhaitable de partager cette perle. Merci à Adrien pour le partage de cette information.

Comme vous pouvez le voir dans app/code/core/Mage/Core/Model/Config.php, l’ensemble des fichiers xml du répertoire etc sont chargés :

/**
 * Load base system configuration (config.xml and local.xml files)
 *
 * @return Mage_Core_Model_Config
 */
 public function loadBase()
 {
   $etcDir = $this->getOptions()->getEtcDir();
   $files = glob($etcDir.DS.'*.xml');
   $this->loadFile(current($files));
   while ($file = next($files))
   {
     $merge = clone $this->_prototype;
     $merge->loadFile($file);
     $this->extend($merge);
   }
   if (in_array($etcDir.DS.'local.xml', $files)) {
   $this->_isLocalConfigLoaded = true;
   }
   return $this;
 }

Donc si vous avez des comportements étranges, vérifiez bien que vous n’avez pas, par hasard, des vieux fichiers de paramétrage XML (ou sauvegarde des local.xml) qui trainent dans votre répertoire app/etc/ de Magento.

La présence dans ce répertoire d’anciennes configuration de fichiers .xml peuvent rendre un site inopérationnel. Par exemple si vous laissez des fichiers local2.xml ou local_save.xml etc., il est possible que vous ayez un conflit de version.

écrit par Philippe Humeau \\ tags: local.xml, magento

Vous vous souvenez surement des Darwin Awards si vous êtes des lecteurs réguliers de ce blog.

Le concept des Darwin Awards est de prendre les plus gros échecs de sites, d’intégration ou de support, c’est de la détente mais ces articles (le MDA I et le MDA II) ont attiré beaucoup de lecteurs.

Aujourd’hui, Vincent et l’équipe d’infogérance NBS System vous propose l’inverse, le top des sites qui envoient le plus ! Ils sont rapides, très très rapides et ces sites sont des petites merveilles de régularité, de l’horlogerie du Ecommerce, sous Magento. Magento c’est lourd ? C’est lent ? En fait c’est surtout dépendant de la qualité du code, comme nous le prouve les exemples suivants et ca peut être très rapide un Magento.

Une démarche positive donc, qui montre qu’avec Magento, une bonne équipe d’intégration, un client sérieux dans ses demandes et un hébergeur qui connait son boulot, on peut tirer le meilleur de Magento. Attention, cet article ne parle que de performances et pas de fonctionnel. C’est la rapidité perçue par l’utilisateur qui m’intéressait.

Voici donc quelques sites, mesurés selon le baromètre suivant :

• Avec la console de Google Chrome
• Chargement complet à l’écran
• Hors streaming
• Hors appels externes (maps, régie pub, trackers, etc)

http://www.linea-chic.fr/
DOM complet : 632ms
Home complète à l’écran : 987ms
Consultation d’un article : 1.43 s / 665 Ko (soit 465 Ko/s, échelle qui ne mesure pas un débit mais un temps de rendu)

Développé par Gabriel Bouhatous. Le site est sur une version CE 1.4 de Magento.
Le développement a prit énormément de temps mais le résultat est là et bien là, un chargement redoutable.

http://www.gazzar.ch
DOM complet : 638ms
Home complète à l’écran : 1.24 s
Consultation d’un article : 1.29s / 324 Ko (soit 251 Ko/s)

Ouch, sous la barre de la seconde et demi, même pour une page produit… C’est un résultat impressionant. Un site qui utilise par ailleurs Nitrogento et donc un Full Page Cache et de nombreuses optimisations. Le résultat est là, le code est également propre, rien à dire c’est un avion de chasse.

http://www.easyparapharmacie.com
DOM complet : 1s
Home complète à l’écran : 2,13 s
Consultation d’un article : 2.1s / 368 Ko (soit 175 Ko/s)

Développé par … Eux. Enfin lui, le patron et deux stagiaires…
Le développement n’est pas parfait, il reste des requêtes qui ne se finissent pas ou des choses un peu étrange mais la rapidité est indéniablement là. Au final, avec peu de moyen et tout en interne, Easy para pharmacie se dote d’un site très efficace. Le temps de chargement d’un produit pourrait être optimisé et le nombre de plugins allégé mais dans l’ensemble, c’est très rapide.

http://www.zadig-et-voltaire.com/eu/fr/eshop/
DOM complet : 489ms
Home complète à l’écran : 1,13 s
Consultation d’Article : 1.7s / 1.18 Mo (694 Ko/s)

Développé par Baobaz sur une version EE (1.8 de mémoire). Le site est riche fonctionnellement, élaboré graphiquement mais toujours rapide et efficace, le FPC de la version EE aide mais ca reste une très belle intégration. On remarque, notamment au temps de load du DOM, que des optimisations ont été menées, Zadig y met les moyens et ca se sent.

http://www.whisky.fr
DOM complet : 1.07 s
Home complète à l’écran : 2.21 s
Consultation d’Article : 753 ms / 450 ko (597 Ko/s)

Un site repris récemment en main par l’Agence DnD après un mauvais départ. La version n’est pas encore complètement nettoyée de ses précédentes souffrances mais ca avance dans le bon sens. Après seulement 3 semaines de travail, l’Agence DnD livre un site déjà nettement plus optimisé, qui charge trèssss vite. Beau boulot, as usual. Bientôt Nitrogento on top, ca va faire très mal.

http://www.lancaster.fr
DOM complet : 1.89 s
Home complète à l’écran : 2.24 s
Consultation d’Article : 2.75 s / 1.5 Mo (540 Ko/s)

A nouveau un site DnD mais avec la particularité de tourner en CE et d’avoir énormément de graphismes, de vidéos, de flash etc. Au final la fiche produit trinque, mais à la demande du client, elle est très graphique, élégante et design. Quand c’est lourd, il faut le charger, mais le débit de rendu reste de 540 Ko/s ce qui est assez impressionnant avec une page (home ou produit) aussi lourde. Bientôt en EE et avec Nitrogento, c’est partit pour être une Ferrari.

http://www.debonix.fr/
DOM complet : 836ms
Home complète à l’écran : 2.6 s
Consultation d’Article : 1.32s / 683 Ko (483 Ko/s)

Au delà du look graphique qui n’est pas très sexy (d’un autre coté c’est de l’outillage, pas des sous tif), le site de debonix charge vite. Là encore, comme Easy para Pharmacie, pas de débauche de moyen et pourtant un résultat très satisfaisant, le site pourrait avoir de nombreuses optimisations et notamment sa home pourrait passer sous la barre des 2 secondes facilement avec juste quelques optimisation et un coup de Nitrogento.

http://www.gemo.fr
DOM complet : 1.11 s
Home complète à l’écran : 1.53 s
Consultation d’Article : 1.68s / 400 ko (238 Ko)

Un site qui est à la fois complet, fonctionnel, graphique et en Magento Enterprise Edition mais qui reste d’une rapidité impressionnante. Malgré des streamings, des appels externe, des graphiques lourds en home, la homepage charge en 1.5 seconde… Wow… La page article elle soufre un peu plus avec un débit de rendu assez moyen mais le site est réactif, particulièrement la home. Bel effort, beau résultat, développé par Adfab.

http://www.motorisationplus.com
DOM complet : 1.05 s
Home complète à l’écran : 1.21 s
Consultation d’Article : 2.41s / 1.37 Mo (560 Ko/s)

Quelques petites erreurs programmatique sur la fiche produit semble être la seule ombre au tableau pour ce site dont la home défit les statistiques. 1.21 secondes, c’est très rapide et tous les sites de la maison sont de la même eau. Simple, épuré, efficace.

Voici donc une  dizaine de sites, qui prouvent clairement que charger en moins de 2,5 secondes c’est très faisable, moins de 2 secondes également et que quand on y passe du temps, qu’on a des codeurs de pointe, un hébergeur spécilisé et quelques optimisation bien placés, éventuellement une version EE, on peut passer sous la barre de la seconde et demi voir même de la seconde. Alors ? Magento ? Toujours aussi lent ?

écrit par Philippe Humeau \\ tags: magento, optimisation, rapide

J’ai enfin eu le temps de le terminer, j’espère qu’il vous sera utile, vous pourrez le trouver ici :

http://www.nbs-system.com/blog/magento-optimization-howto.html

écrit par Philippe Humeau \\ tags: magento, optimisation, performance, serveur

15 points à vérifier avant une mise en production Magento

1. Désactiver le mode DEBUG de Magento, véritable gouffre à performance
2. Réactiver ses Caches (Magento & Reverse proxy) souvent désactivés lors de la phase de développement
3. Passer les vérifications du W3C (http://validator.w3.org/ et http://jigsaw.w3.org/css-validator/). Un site ne doit pas comporter d’erreurs HTML ou CSS pour être optimal et ne pas pénaliser ses performances, notamment l’interprétation des navigateurs web.
4. Demander à son hébergeur si toutes les optimisations basiques sont activées de son coté (ramdisk ou memcached pour les sessions, APC, Zend server ou Eaccel pour l’opcode caching de PHP, etc.)
5. Vérifier ses résultats sous Pagespeed (80% est un minimum à atteindre)
6. Vérifier le chargement de la page sous dragonfly, firebug ou chrome
7. Passer un crawler de 404, histoire de ne pas laisser des ressources inaccessibles (vérifier les erreurs 500 dans les logs apache également)
8. Vérifier ses Cron et leurs temps d’éxécution
9. Toujours avoir un backup et intégrer sur la préprod
10. Ne jamais faire sa migration un vendredi soir ou un Week End
11. Lancer le site au moins une semaine avant toute opération importante, surveiller son fichier system.log dans [site Magento]/var/log/system.log
12. Faire une vraie recette de son site avant de passer en production, chaque fonction doit être vérifiée
13. Monter en puissance progressivement (pas de mailing de 180000 personnes sur un site tout frais)
14. Surveiller ses consoles de supervision pour voir si les serveurs ne montent pas au plafond d’un coup en charge
15. Surveiller ses slow requests Mysql pendant une petite semaine (c’est un peu couteux en performance, il parait donc important de ne pas le laisser en permanence)

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

Les soldes, ce moment critique

La grande majorité d’entre vous ne l’ignore pas : c’est les soldes.

Et la plupart du temps, les soldes, c’est un moment de grandes ventes pour les sites de E-commerce, de 15 à 30% du CA de l’année peut se jouer sur cette étroite période de 15 jours. En fait, techniquement, le CA est même concentré sur les deux premiers jours majoritairement.

C’est donc un moment à ne rater sous aucun prétexte.

Bien que ce blog ait été dédié à Magento pendant des années, nous (NBS System) travaillons aujourd’hui  avec de nombreux frameworks : Drupal Commerce, Prestashop, Hybris, Oxid et bien sûr toujours avec Magento.

Actuellement sur 800+ sites hébergés, nous avons 4 sites avec des problèmes. Les 4 sont des soucis applicatifs et nous n’avons (je touche du bois) aucun pépin en exploitation, hébergement, infogérance. Mais ces problèmes proviennent de cas classiques alors autant vous faire profiter de notre expérience. Le seul glitch important, c’est le plantage d’un noeud majeur de routage en France, qui nous a impacté indirectement 10 minutes avant que nous ne passions par d’autres routes.

Mettre en production son site de E-commerce

Il est tentant de mettre en place son nouveau site pour les soldes mais c’est une très très mauvaise idée.

Conseil 1 : ne pas mettre un site en production « juste avant les soldes »

Une nouvelle release d’un site peut tout changer.

Changement de comportement, changement de design, de charge de travail pour les serveurs, c’est tout un art délicat. Le principe de précaution veut que l’on mette en place le site quelques semaines avant, disons deux au minimum. Ensuite un petit test de monté en charge, simulé avec des outils ou directement avec un mailing d’animation commercial sera un garant du bon comportement (ou non) du nouveau site.

Rater le premier jour des soldes est un désastre que l’on ne peut se permettre, mieux vaut tourner avec la version précédente du site pour assurer dans le doute plutot que de tenter par tous les moyens d’avoir le tout dernier gadget ou le nouveau tunnel de vente. Au pire, un mailing qui montre un soucis sur le site 15 jours avant laisse le temps aux experts de se concerter et corriger le tir. PRECAUTION on vous dit !

Conseil 2 : Analyser avec quelques outils simples

Afin de partir tranquille, vous pouvez par vous même faire quelques tests simples.

W3C validator

Le W3C c’est l’organisme de validation de la norme HTML. This is the law.

http://www.W3C.org/validator

Si votre site n’est pas propre, cela rendra des erreurs dans les différents navigateurs et la pollution visuelle et/ou technique pour le visiteur sera désagréable. Le site permet de valider le site en HTML et au niveau de ces CSS. Le gros avantage, c’est qu’il vous pointe les erreurs directement avec les lignes. Balises non fermées, problème de consistance, grammaire incorrecte.

C’est un minimum avant de partir en production que de passer ce test avec  succès ou au moins sans casse majeure.

W3C CSS validator

http://jigsaw.w3.org/css-validator/

même principe, mais pour les CSS.

Firebug, Dragonfly, Webdevelopper, etc.

Les navigateurs avancées (Firefox, Opera, Chrome) vous  permettent d’analyser vos pages et les temps de chargement des différents composants. Pour ne parler que du plus célèbre, Firebug est un outil en or. Vous pourrez y trouver des informations très intéressantes sur le chargement de vos pages. Ce qui y est chargé, comment, à quel vitesse (parfois combien de fois).

Si vous chargez 2 fois une librairie JS de chez Jquery, vous aurez peut être des conflits, si vous avez 20 javascripts cela va compliquer la tache du browser. Avoir des CSS bourrés d’erreurs de grammaire complique (et donc ralentit) le rendu par le navigateur. Charger des composants externes (depuis d’autres sites/serveurs) peut ralentir votre page, voir la bloquer parfois.

Les consoles de debug des browsers peuvent vous aider sur tous ces points alors profitez en, de plus le rendu est assez lisible et compréhensible, même si vous n’êtes pas développeur (comme moi par exemple).

Ça ressemble à ca :

On est sur un site très bien conçu dans le cas présent, je n’ai montré aussi que le début du load mais il y a beaucoup plus d’éléments.

Sur la console nous pouvons voir les onglets Tous (tous les éléments) puis chacun d’entres eux un par un. Vous pouvez aussi analyser votre HTML, vos CSS, vos JS, votre DOM et tout cela en un seul outil.

Les erreurs faciles à détecter avec cet outil :

• Ressources dont le chargement ne se finit pas (petit cercle qui tourne en continu et barre qui s’allonge)
• Ressources externes lentes à charger (logo paypal depuis le site us par exemple ou un JS sur le serveur d’un prestataire)
• Ressources chargées de multiples fois (CSS/JS, parfois même la homepage rappelée par la homepage, sisi ca s’est vu)
• Erreurs 404, 501, 201, ou code de redirection 301/302 par exemple
• Temps de chargement du core (première ligne, sur cet exemple 317 ms, ce qui est un bon temps pour Magento)
• Temps global de chargement
• Poids global du chargement (on va parler des « valeurs » repères plus bas)
• Temps des attentes, réception et résolutions DNS
• Nombre de composants externes appelés
• Temps avant le chargement complet du DOM Vs temps de chargement complet
• Temps de rechargement une fois la page chargée une première fois

Pas mal pour un seul outil non ?

Yslow, Pagespeed, Gtmetrix,

Mes grands amis. Ils donnent des axes d’améliorations et d’optimisations de votre site tout en vous donnant une « note ». GTmetrix est une interface Web qui vous permet d’utiliser les plugins Yslow & Pagepeed (essentiellement compatibles Firefox) sans avoir Firefox. Ces deux jeux de règles d’optimisations de Yahoo et Google sont utiles, bien pensés et accompagnés de conseil en ligne ou directement dans l’interface. Vous pouvez avec ces outils :

• Détecter les images non compressées (ou pas assez)
• Les CSS mal codés
• Les optimisations de type gzip/etag/expire headers
• Le fait d’avoir ou non un usage des CDN/medias serveurs
• la compression et minify des CSS/JS/HTML
• les 404
• et de nombreux autres points.

Avoir un B/B sur GTmetrix est relativement simple pour peut que l’on optimise un peu son site et son hébergement et c’est assez agréable au surf pour le visiteur au final.

Les sites web de tests

Trois très bons sites qui vont vous donner des indications précieuses : (n’oubliez pas que la plupart sont aux US et donc que les temps de chargements sont souvent plus élevés à cause de la latence réseau)

http://www.whichloadsfaster.com/

Comparaison entre deux sites sur les temps de chargements. C’est simple mais assez efficace. Si vous avez votre ancien site sur un serveur et votre nouveau sur un autre, cela peut être un très bon bench.

http://websiteoptimization.com & http://www.webpagetest.org/

Simple, efficace, beaucoup d’informations censées et lisibles ressortent de ces deux sites.

Munin & Google Analytics

Deux outils simples chacun de leur cotés. Munin (et d’autres) donnent des informations sur les statistiques vitales de vos serveurs (charge  CPU /RAM / DISQUE / BP etc). C’est un outil, qui est en général, mis à disposition par votre hébergeur (celui-ci ou un autre équivalent). L’intérêt est de pouvoir coupler les informations, par exemple slow queries, activité réseau et CPU pour avoir un diagnostique d’une panne ou d’un ralentissement.

De son coté, Google Analytics intègre maintenant le temps de chargement des pages. Très utile pour voir l’évolution dans le temps de ceux-ci. Voir mon précédent post ici.

Zend server

La console de Zend Server aide notoirement à identifier les coup de rame du site. Une des clefs : le code tracer. Cet outils permet d’analyser les exécutions PHP qui sont les plus lentes et à pointer directement les lignes en cause. C’est assez bluffant et cela réduit habituellement considérablement les temps de recherche des bugs.

D’autres outils ont été posté dans un précédent article ici.

Conseil 3 : Le Test de charge

Le test de charge c’est une clef de succès. Le fait de faire réaliser un test de charge par votre hébergeur avant la mise en ligne vous permet de savoir où vous aller.

Ce n’est pas une vérité absolue car on ne peut pas simuler tous les comportements utilisateurs mais, en général, si un gros pépin arrive à l’horizon en terme de performances, le test de charge le montrera. Sur les sites assez simple, on arrive même à une précision d’environ 5 à 10% de la réalité, ce qui est très intéressant.

Quelques points de repères

JS : 4/5 par page semble une valeur raisonnable. Concaténé cela peut se réduire à un si le site est bien codé mais dépasser 10 est, en général, une mauvaise idée.

CSS : 3/4 maximum, de la même façon, cela peut se concaténer en un fichier.

Images : 50/60 maximum, si possible. Après ca devient un peu lourd à télécharger et donc long pour peupler une page. Tout le monde n’a pas une 20 Mb/s à la maison.

Nombre total d’éléments sur la page : 80 semble un maximum, après on est dans une zone orange, à plus de 100 c’est exagéré.

Nombre de produit par page : Magento conseil quelques dizaines au maximum pour le load.

Taille de la page : 1 Mo max. C’est presque trop d’ailleurs. Au moins à l’initial loading, après du streaming peut arriver en route ou du javascript (Ajax) charger en background.

Temps de chargement : 1 seconde ou moins on est au top, 2 secondes c’est correct, 3 c’est limite, 4 ca comment à être trop, 7 ca devient insuportable, 10 le client est partit. Bien sur, c’est le temps avant que la page soit visible et les menus réactifs. Il peut continuer à se passer des choses après, c’est moins important.

GTmetrix : avoir une note de B/B est très faisable sans engager des sommes folles et cela améliore l’expérience client ! A/A cela demande plus de travail mais l’on obtient rien sans rien Le site de NBS System en est à 96/94 et cela nous a prit 3 J/H de plus (mais c’est un peu notre dada).

Ratio entre visiteur uniques par jours et visiteur simultanés en pic : en général on considère un facteur 200 à 400 sur un site normal. Ce qui veut dire que si vous avez ~20 000 visiteurs uniques par jours, vous pouvez compter que votre crête de fréquentation à un moment donné sera de ~100 à ~200 personnes connectées simultanément. La valeur moyenne que nous retenons en général est 280.

Nb de visiteurs unique pour un serveur (valeur pour Magento CE) :

• Petit VPS (2 cores 5650 / 2 Go) : ~5000 VU/j
• Gros VPS (8 cores 5650 / 2 Go) : ~20 000 VU/j
• Gros serveur  dédié : ~40 000 VU/j
• Serveur dédié + DB dédiée : ~60 000 VU/j
• Infrastructure : 50 000 Visiteurs uniques par jour par Web frontaux, 80 000 en enterprise ou avec Nitrogento.

Extend To Cloud (E.T.C)

Le système exclusif créé par NBS System permet, en 3 minutes 30, d’apporter du renfort avec des machines de Cloud. Avec l’usage de SAN, l’overhead de la virtualisation est réduit à 4% et les performances sont donc parfaitement comparable à une machine physique.

Par contre, le fait de pouvoir les mobiliser au moment du besoin, pour les soldes, pendant les ventes de fin d’années, c’est une force indéniable. Parfois, les clients nous préviennent au dernier moment d’un passage télé, pas de soucis, E.T.C amène des renforts en quelques minutes.

Le gros avantage, c’est que la facturation ne se fait que sur la consommation et non tout au long de l’année. Si un E-commerçant fait ~20 000 visites par jours en temps normal, il tient sur un serveur. Si il fait 100 000 pendant le premier jour des soldes, il n’a besoin de serveurs de Cloud que pendant un jour et n’est facturé que pour une journée. Économique et efficace !

Plus d’information ici.

Tools & méthodes d’optimisations

Data URI : Pour les petites images, moins de 2 K€, il est intéressant de les intégrer sous formes de chaine texte dans le CSS (en plus ca se compresse), pour la méthode, voir ici : CSS URI

Zend server : Le soft fournit une stack PHP robuste et optimisée avec des capacités de FPC et un accélérateur d’opcode du style APC.

Optimisation progressive et dégradation élégante, voir l’article ici.

Nitrogento : une extension spécifique pour Magento qui boost méchamment les performances. (Voir le lien sur les performances)

Magento Enterprise Edition : Elle embarque du Full Page Cache, ce qui aide pas mal au rendu des pages.

Serveur de Média ou CDN : cela permet au client de rappatrier les données plus vite et plus prêt de chez lui.

Fooman speedster : Un module qui fait la concaténation des JS et CSS (Nitrogento le fait aussi)

Après d’autres framework ont des extensions d’optimisation spécifiques (comme W3TC pour WordPress par exemple) et bien sûr il y a beaucoup à faire du coté serveur, ce que votre infogérant devrait faire pour vous. Par exemple pour Magento, nous avons environ 20 optims spécifiques aux serveurs ou dans l’architecture.

Conclusion

Don’t take any useless risks, optimize, sale !!!

écrit par Philippe Humeau \\ tags: e-commerce, magento, soldes

Ebay & Magento

Depuis cette annonce officielle du début de semaine, les couloirs du monde du E-commerce bruissent de questions, de fantasmes, d’idées sur ce que signifie ce rachat, sur ce qu’il va changer au niveau de Magento et de la solution. Depuis 5 jours, j’ai eu une pelleté de mail pour me demander mon point de vue sur ce changement, tout comme les autres responsables communautaire en Allemagne, en Angleterre ou dans d’autres pays.

Je tiens, avant d’aller plus loin, à signaler que ce qui va être dit ci-dessous n’est que le reflet de ma propre opinion et en aucun cas une information « de l’intérieur » ou un avis « corporate de Magento Inc« . Depuis 3 ans que je fréquente Roy, Yoav et plus récemment Bob, je suis devenu assez proche d’eux pour échanger régulièrement mais rien d’exclusif ne m’a été annoncé « en private ».

Par contre,  on travaille sur la première interview officielle de Roy Rubin suite au rachat de Magento par Ebay en ouverture du Bargento. Ce n’est pas encore finalisé mais nous travaillons ce point et il est probable que j’interviewe Roy Rubin & Yoav Kutner en guise de « Keynote » pour l’ouverture de Bargento 2011.

Be there, tout sera dit, évoqué et on devrait avoir « du lourd ». Envoyez moi vos questions si vous en avez, j’essayerai de les poser !

Quelques semaines que…

Depuis le début de l’année, le mouvement me paraissait logique (je vais y revenir).

Depuis Meet Magento 5.11, les rumeurs étaient dans l’air.

Depuis lundi, il n’y a plus de mystère. Même si un contact bien placé chez les VC m’annonce qu’il y a encore un peu de paperwork, l’agreement est signé. Nous parlons donc ici d’un rachat complet de Magento Inc par Ebay. Les quelques actions qui étaient émises en stocks seront probablement compensée en action Ebay ou en cash, celle de Roy & de Yoav ont été vendues à Ebay.

Nouveau ? Non je ne pense pas. Pour moi (et là encore, ces allégations n’engagent que moi), quand Ebay a signé la première partie des 49% des parts de Magento, le deal était déjà prévu pour se finir par un rachat complet à un an, sous condition de réussir quelques objectifs. [NDA 11/06/2011 : J'ai eu une information contraire depuis et il semble qu'Ebay n'avait pas déjà prévu la deuxième partie du deal dès le début]

Pourquoi ? Car c’est une méthode habituelle de procéder dans ce genre de cas. De plus Ebay n’a pas pour habitude de faire des investissements minoritaires, encore moins dans un secteur clef pour eux. Enfin, Magento, aussi prometteur qu’ai pu être la solution en 2010, n’était qu’un embryon. Avoir un an de plus pour confirmer les résultats semblait logique.

La stratégie globale d’Ebay

Évidemment quand une société comme Ebay investit, ce n’est pas au hasard ou par pur opportunisme. Bien que l’achat opportuniste existe sur ce marché, il reste de toute façon dans les bornes d’un plan stratégique long terme du type « dominer le monde et les galaxies avoisinantes à terme de xx années ».

Dans le cas d’Ebay, à mon sens, il suffit d’analyser la situation actuelle du marché mondial du E-commerce et mettre en parallèle les acquisitions récentes pour comprendre le schéma. D’ailleurs, parlant de X.commerce, il faut se souvenir que fin 2009, Ebay avait déjà parlé de X.com avec PayPal X, le plan ne date donc pas d’hier !

Amazon domine le marché dans une quinzaine de pays et a développé des armes fatales :

• un service client béton
• un site qui est quasi parfait en terme d’IHM et sert d’exemple partout dans le monde
• un système logistique au-delà de tout ce qui a pu exister
• un système de Cloud pour rentabiliser son architecture tout en empochant une manne impressionnante

Ebay lui a été le pionnier dans son domaine mais :

• les ventes du grenier de mamie ne représente plus que  25% des ventes d’Ebay, 55% sont de l’achat direct et le reste est représenté par les ventes / annonces de voitures/immo
• Dans les 55% de ventes directes nous avons ni plus ni moins à faire à un gros porteur du SAAS avant l’heure, à des marchands qui se servent d’Ebay comme plateforme
• Paypal est une banque dédiée à l’Ecommerce, possédée par Ebay, c’est l’équivalent de l’arme secrête Cloud d’Amazon pour Ebay
• Le géant aspire a devenir une marketplace mondiale (comme priceminister ou Pixmania en FR) pour concurrencer Amazon a sa façon

Du coup, Ebay se place en concurrent directe d’Amazon sur un marché légèrement différent, avec des armes qui lui sont propres et un réseau existant.

Mais il manquait à cet arsenal quelques clefs :

• 2010 : Investissement dans Magento Inc
• 2011 : Rachat de GSI
• 2011 : Rachat de Where
• 2011 : Rachat total de Magento Inc

Ces mouvements ne visent tous qu’un but : pousser Ebay vers son futur, remettre la société dans le match pour la place de leader mondial. Il y a fort à parier que pas mal d’autres acteurs vont tomber dans les grands filets d’Ebay qui va acheter du « best of breed » pour combler son retard.

Ma mise pour les prochains rachats : d’autres acteurs de la chaine de valeur : logisticiens, web marketing, mobile marketing, M-commerce, hébergeur (Cloud) et outils de CRM/ERP. La gamme de service va se compléter et Ebay montera ou rachètera ce qui lui manque.

le X.commerce par Ebay

Déjà les briques :

• Ebay
• Magento
• Paypal
• Omniture
• Terapeak
• Where
• Milo
• Kenshoo
• Redlaser
• Adobe
• GSI commerce

Chaque briques est clef et Ebay a créé un lien direct (achats, contrats, partenariat) avec toutes ces technologies ou sociétés. Le but est réellement d’avoir le positionnement le plus large possible en terme de service. Commerce de proximité, géolocalisation, connecteur de payement, couponing, délégation, code bar (par Red laser, pour les POS), digital marketing,  Analyse & BI, solution… Ça avance à grands pas, quelques acquisitions ou partenariats de plus (M-commerce ? M-marketing ? Régie publicitaire ?) et le paysage sera très complet !

La plateforme restera ouverte afin que les clefs comme PayPal ne soient pas uniques et ne bloquent pas les autres technologies ou fournisseurs. L’idée derrière X.Commerce est d’être un « Open Ecosystem » afin de ne pas limiter l’expansion de la plateforme.

Magento qui intégrerai Milo ? Ebay dans le BO de Magento ? Toutes ces couches vont se renforcer et se liées petit à petit dans le temps, peut être vers une API complète qui couvrira plusieurs acteurs de la chaine à mon sens.

Position de Magento dans cette stratégie et vs GSI ?

C’est une grande question mais X.Commerce est un projet d’envergure et je pense qu’il est très structuré en « gamme ». Le but est de fournir un service de plus en plus complet qui ira jusqu’aux entrepôts, l’acheminement, la facturation, la connexion aux outils de l’entreprise (ERP/CRM), l’hébergement, le marketing, l’advertising etc.

Mais il est probable, quand on joue à la taille d’Ebay, que les segments soient très clairs pour Ebay :

• Boutiques Ebay & particuliers / TPE : Magento GO
• PME / Mid-size : Magento CE / PE
• Top 5000 worldwide retailers & merchants : Magento EE
• Top 500 worldwide retailers & merchants : GSI, ceux qui font ou feront 1 millard de dollar ou plus en ligne

Après, le travail d’analyse devient plus complexe. Il est relativement connu que la plateforme technique de GSI est assez moyenne. Ce qui démarque la société c’est son offre de service. Fusionner Magento et GSI en terme de plateforme n’a pas de sens à mon avis, il est donc probable qu’a terme Magento équipe GSI pour remplacer son offre technique. GSI pour le service, Magento pour la plateforme, Paypal pour le payement, X.commerce commence à prendre forme non ?

Les composants sont là, les services aussi, les clients déjà existants pourront migrer, les futurs clients auront une facilité d’intégration indécente entre le connecteur de payement, la plateforme et les services… Et dans ce cas, qui pèse lourd ? Le premier marchand en ligne au monde ou les millions de « petits » sites marchands ?

Dans le doute, Ebay joue double, il concurrence Amazon en prenant le low market à grande vitesse, tout en faisant fructifier sa banque (PayPal) et adresse aussi le segment haut de gamme avec GSI. La version Enterprise de Magento se place tout naturellement dans ce jeu, au milieu, pour le segment moyen de gamme.

Surtout, cette largeur dans le spectre permet à Ebay d’accompagner la croissance des clients, de sa phase de démarrage sur GO jusqu’au E-commerce par délégation avec GSI. Ebay pourra couvrir toutes les phases de la croissance de ses clients, avec une palette de services qui s’élargira au fil du temps.

Jouer au petit poucet

Les indices se balladent mais les mettre bout à bout est complexe. Entre Bargento, Imagine, Magento Dev Paradise & Meet Magento,  il faut être presque partout pour voir le big picture.

Après ce dernier Developer Paradise à Ibiza, nous avons pu avoir un peu d’informations sur les évolutions de Magento et clairement la roadmap est très soutenue, ce qui implique, pour moi, que la solution est très pérenne. En fait ce rachat par Ebay va renforcer le produit, les fonds de la société et les fonctionnalités de Magento, plus probablement le produit va s’ouvrir avec un gros webservice.

Yoav a parlé de Soap, Rest, RPC-XML et de loose coupling, c’est de l’ouverture au possible tout cela, le PHP restera la clef, ainsi que l’open source en tout cas.

De plus à Imagine en début d’année, Yoav annonçait aussi que la base de développement technique pour toute la plateforme Magento (GO, CE, PE, EE, Mobile) sera la même en terme d’API ce qui permettra à un grand nombre de modules d’être compatible sur toutes les plateformes.

Webservice, ouverture, API, tout cela converge vers une grosse plateforme bien ouverte pour moi.

Ecommerce par délégation et multi canal : la clef ?

Quand on souhaite jouer à cette échelle, il devient nécessaire de pense Multi Canal. En effet les retailers, qui sont ceux qui tirent le marché du E-Commerce actuellement, sont souvent doté de POS (Point of Sale), de catalogue papiers, de canaux de ventes indirectes et rêvent de mobile en plus de leurs sites Web.

Regrouper tous ces canaux de ventes ne  se fait pas en claquant des doigts et les solutions de E-commerce se doivent d’être de plus en plus agiles. Si je me fie à ce que je vois dans le prochain Bargento, 40% des animateurs, exposants et speakers vont parler d’une forme de Multi-canal ou d’une autre. La tendance est lourde.

Sur la délégation, même combat. Les plus grandes marques veulent se concentrer sur leurs cœurs de métier, le design, le marketing et la production mais le modèle Vente Privée à prouvé qu’ils sont aussi d’accord pour céder une partie de leurs marges en contrepartie d’un service complet. Les acteurs comme GSI, Mix Commerce, DCF, Baobaz et de nombreux autres visent ce marché et vont s’y battrent pour convaincre les retailers que la solution de la délégation est la meilleure économiquement.

Évidemment, faire converger Délégation et Multi-canal va de soit alors je reste persuadé que ces modèles vont dominer la scène à moyen terme sur le segments des retailers. Avec sa nouvelle force de frappe et son projet X.Commerce, Ebay va jouer un rôle clef sur ce segment.

Et les autres géants ?

Il semble improbable qu’Oracle, Google, Microsoft et IBM ne réagisse pas.

Oracle a racheté ATG, probablement pas pour faire de la figuration. Microsoft a beau avoir des ennuis actuellement, la société n’a pas l’habitude d’apprécier être en queue de peloton et possède des moyens colossaux pour revenir dans le jeu (à moins qu’elle ne décide de passer outre cette bataille).

IBM a du accuser le coup du rachat de SUN par Oracle car Websphere Commerce repose assez largement sur Java mais la maison reste puissante, le soft connu et certaines sociétés sont encore dans une mentalité « Personne ne s’est jamais fait virer pour avoir choisit de prendre IBM ».

Amazon ne va pas rester sans rien faire et son offre sur la partie mobilité semble un peu faible, c’est probablement sur ce créneau que le géant va contre attaquer. Décidément, les opérateurs de M-commerce vont valoir une petite fortune à court terme je pense. Il est possible aussi que, toujours avec un cran d’avance ce soit les médias de type télévisions connectées qui occupent le géant.

Apple reste un des leaders du E-commerce indirectement. Avec le plus grand nombre d’application pour mobile vendu dans le monde, une domination insolente et sans partage du segment des app, des mobiles haut de gamme, de la vente de musique et des tablettes, il serait étonnant que la firme de Cupertino choisisse de ne pas mordre de cette pomme.

Oublier Google irait si vite si ils n’avaient pas déjà les mails, les téléphones (OS au moins), les plannings, le moteur de recherche, l’advertising, et tout le reste. Qui peut rivaliser avec Google alors que c’est le premier vecteur de trafic naturel et payant pour un site de E-commerce ? Qui pourra s’alliera avec ?

Google Wallet n’est pas une initiative innocente quand l’on voit que le procès est partit presque immédiatement et que les personnes recrutés sont des anciens pontes de PayPal. En résumé, il parait impensable que Google ne viennent pas jouer des coudes dans ce marché, d’autant que sa position, google shopping et panda sont autant d’indices qui tendent à montrer un fort intérêt de la marque pour le Ecommerce. Android constitue une excellente base pour développer du M-commerce par ailleurs.

Et les autres technos ?

Hybris : Un ovni vient de faire son apparition sur le marché haut de gamme. Pourtant la solution existe depuis plusieurs années mais les Suisses sont des gens discrets par nature alors on en entend parlé que depuis peu de temps. Fort de plusieurs dizaines de millions d’euros de CA, d’un casting d’ex dirigeants de grands groupes et d’une techno béton, Hybris s’impose.

Et quand il s’agit de scaler, de grossir, de gérer des dizaines de millions de produits, le petit nouveau convainc sans problème les grands comptes de son efficacité, de sa souplesse et de la vertu de reposer sur un langage fortement structuré. La solution coûte cher (on parle en ceintaine de milliers d’euros pour les licences) mais fait (presque) tout. Le product manager est dédié au multi-canal nativement alors oui, il va falloir compter avec Hybris quand on parle de haut de gamme et comme Magento en son temps, il a fait son apparition dans le beaux tableau du Forrester research group.

Commerce Guyz & Drupal Commerce : Quand on a quelques centaine de milliers de développeurs formés à sa techno, on part avec un certain atout. De la même façon, quand on est le successeur d’Ubercart, la partie n’est pas la même, on est juste attendu. Avec sa très très forte composante CMS qui manque cruellement à presque tous ses concurrents, Drupal commerce va frapper très fort. De plus la technologie est modulaire à l’extrême, imaginer la souplesse de Drupal, allier à la force du Ecommerce, c’est presque effrayant.

Prestashop cherche à lever des fonds pour soutenir ses ambitions et tente l’aventure Américaine avec l’un de ses fondateurs. Le produit fait tout pour se débarrasser de son image de solution pour « les petits sites » et reste un pionnier historique du modèle SaaS à sa façon. La solution existe depuis plus longtemps que beaucoup d’autres dans le marché mais son histoire semble accélérer maintenant. Dans un marché avec de tels players, Prestashop cherche à sortir de l’hexagone pour aller à l’international, un mouvement que tente Oxid en Allemagne ou son redoutable concurrent RBS en France.

RBS Change est un produit très efficace, propre et arrivé sur le marché depuis 3 ans. Les fondateurs sont Français et c’est encore un fleuron du E-commerce de plus qui est né dans l’hexagone. Le backoffice en XUL est très pratique et original, même s’il impose d’utiliser Firefox pour son backoffice, le produit est novateur, rapide et extrêmement performant. Dans les framework PHP, c’est un des plus véloces en fait. La richesse fonctionnelle est là et la société fait évoluer son modèle économique, son produit et son marketing, je pense qu’ils font partit des « emerging player to watch ».

Oxid Esales est le leader de la solution E-commerce en Allemagne. Rien que ce fait impose le respect car le marché Allemand est exigeant, déjà très structuré et mature. Alors quand on part avec d’aussi bonnes bases (largement dominant en Allemagne), que les clients références sont légion et le feedback très positif, il reste à partir à la conquête de l’Europe et du monde. Encore un acteur de la taille d’Oxid ou de Prestashop avec de fortes prétentions et toutes les raisons d’y croire !

Les autres SaaS :  Oxatis, Powerboutique, Demandware, et beaucoup d’autres sont à la chasse. Des petits pour les deux premiers aux grands pour le troisième, chacun cherche à convaincre que son offre est la plus adapté à un segment de marché mais les autres acteurs « framework » arrivent aussi avec leurs propres prétentions, RBS, Drupal etc. Ca va donc être un marché très « dynamique » et ultra concurrentiel.

Les autres technos existantes : WCS, ATG, Microsoft commerce et beaucoup d’autres framework moins connus, tous ces acteurs ne se coucheront pas et vont aussi jouer leurs cartes, petits ou grands les risques et les opportunités restent énormes, comme me le disait un ami (qui est un des boss d’un des top 5 sites français), « on en est à peine au début en matière de E-commerce ».

Alors qui va se faire racheter par qui ?

Quelques cibles qui semblent attractives :

• les sociétés spécialisées dans le développement sur mobile, tablette et tactile. Plusieurs acteurs de tailles moyenne font déjà un bon boulot avec une bonne expertise, Mobile Roadie ou Adyax par exemple.
• les frameworks (pour leur valeur intrinsèque et pour leur portefeuille client), Ebay est équipé mais quid des autres acteurs ? IBM ou Oracle pourrait craquer pour Hybris, un autre des géants pour Oxid ou RBS pour se faire un SaaS à lui, les opportunités ne manquent pas.
• les régies de publicité (online et sur mobile)




Mais peut être aussi :

• les logisticiens (entrepôts, automates, roulage, livraison)
• société de marketing digital
• les intégrateurs (pour la croissance externe de plus gros intégrateurs)
• les opérateurs de Cloud privé

Le grand plan d’Ebay

Finalement, en quoi consiste « The Big Picture » pour Ebay ?

Je parie sur les points suivants :

• X.commerce : Un hub business où prendre des marges sur les différents services, tout en le laissant ouvert pour que toutes les techos puissent y jouer.
• Offrir un parcours complet pour le commerçant : Ebay->Go->Magento CE->Magento EE->GSI avec de la valeur à chaque étape, probablement adossé à un Cloud pour se concentrer sur l’offre de service plus que sur la partie sous jacente.
• Et surtout… Faire fructifier la plus grande banque du monde. Car avec 300 Millions de comptes, majoritairement d’européens et d’américains, PayPal c’est un peu la nouvelle banque du monde du E-commerce et accessoirement, un des plus grande banque de retail au monde. On peut y émettre des devis, se faire payer, payer avec une dizaine de méthodes différentes. Le plan secret, plus que le service End to End, pour moi il est là : faire de la marge sur des centaines de millions de comptes bancaires. 300 millions de comptes, des dépenses qui vont avoisiner les 1500 € par têtes en moyenne par an, prendre un petit pourcentage de cette manne, c’est être très grosse banque dans le monde non ?

écrit par Philippe Humeau \\ tags: ebay, gsi, magento, rachat, stratégie, x.commerce

Foreword

After some months in the field of Magento managed hosting, NBS System decided to create a new Magento extension : Nitrogento.

This extension aims at giving more performances to Magento shops. Mainly, 7 points are covered (more will come with our strong roadmap) :

1. Full Page Cache
2. Block Cache
3. Custom Bloc Cache
4. Auto Sprite
5. HTML, JS & CSS minifying & compression
6. HTaccess fine tuning
7. CDN auto deploy

Magento Benchmark with Nitrogento

The benchmark context

This said, the main key here is the performance. So what best way than making benchmarks ? Well we tryied almost all of them ! And I’ve to say that there is a lot of benchmarks around !

We installed a basic demostore on http://demostore.nitrogento.com and did the same demostore with Nitrogento on http://nitrostore.nitrogento.com. The server hosting the demo/nitro stores is the very same, actually, it’s even the same machine. The machine was a Quad core 5650 VPS with 8 Go of RAM.

Benchmark used

We choosed to used the following benchmarks, which are considered the most accurate and renowned :

• funkload
• www.gtmetrix.com
• www.magespeedtest.com (Siege)
• Firebug
• www.whichloadsfaster.com
• www.webpagetest.org

PS : We know some of you love our product but, please, can you consider doing your benchmarks on your own servers, or at least not to often on ours, because recently we had a lot of people benching both sites (http://nitrostore.nitrogento.com and http://demostore.nitrogento.com).

The benchmark issues to be considered

Some tests gave a false results for two reasons :

- First, the  server is located in France. So when you use GTmetrix (for exemple) the test server is located in the US. This means that we have a bit of lag between the test machine and the target machine. One in the other, this is not a big issue since only the real load time is false but the comparison stay exact since both Nitro & Demo stores are located in France so they are in the exact same situation.

- We also found a funny problem. Google and Yahoo (and many others) recommand using multiple CNAMES/HOST to host the static files. That way, your browser is able to download a lot of file at the same time and not only 8 by 8 or 12 by 12 (the exact multi thread number is browser dependant). But when you have several CNAMES pointers, this makes several DNS resolutions and … this can be a problem depending on various factors. The precise problem came up with www.wichloadsfaster.com (WLF). By make 5 DNS requests on Nitrostore and only 1 on Demostore, he claimed that Demostore was faster.

Actually this is not true, but the 4 more NS lookup took a bit more time (resolution from US to France) and as WLF only test the core load (don’t take the pictures, CSS, Js again) it found Nitrostore to be slower. So to get realistics results, the WLF test was made with the CDN feature of Nitrogento desactivated, to avoid having more DNS lookup to do than on a basic demostore. In real life, this CDN feature bring you a lot and we recommand it, of course

We noted these troubles in the table of results.

(*) stands for « longer time than real since test machine and bench machine are in US and FR »

(**) stands for « desactivated CDN not to compromise results »

Results

Nitrostore : 2,4 times faster.

Nitrostore : 43% faster
Nitrostore : +20% to yslow/pagespeed tests

Nitrostore : 2,2 times more transaction per seconds
Nitrostore : 3,38 times faster per request

Nitrostore : 42% less HTTP resquests
Nitrogento : 37% faster to load
Nitrostore : 40% less bandwidth / transfer

Under heavy load,
Nitrostore : up to 18 times faster on the homepage and 3 times faster in the full scenario
Nitrostore : up to 12 time more home page served and 3 times more full scenario
Nitrostore : Continuous perfect APDEX on homepage and 15% better APDEX indice (user experience) on complexe scenario

Trial version

But you know what ? Test it by yourself, there is a Trial version there : www.nitrogento.com

écrit par Philippe Humeau \\ tags: boost, booster, load time, magento, optimisation, performance

Quelques outils intéressants

Nitrogento

Eh oui, il arrive…

Après 6 mois développement et deux de Beta tests, des semaines de création de sites et de traduction de documentations, de benchmarks et de tests, voici qu’approche la sortie de Nitrogento !

Cette toute nouvelle extension pour Magento va vous permettre d’obtenir un « All in one » d’optimisation :

• Création du Sprite et patch du thème
• Ventilation des ressources statiques sur les CDN
• Concaténation, Minify et Compression des JS & CSS et du HTML
• Block caching des blocs qui ne sont pas déjà dans le cache Magento
• Custom Caching, mettez votre propres blocs « maison » dans le système de Cache Magento
• Full Page Cache, ehhhhh oui, même pour la CE !

Autant dire que ca va légèrement dynamiser votre site… De plus, les fameux blocs maisons (custom) qui ne sont pas gérés actuellement par le cache de Magento pourront y être intégrés grâce aux Hooks que crée Nitrogento pour vous.

On va passer de Moogento à Maaaaagento, moi je vous le dis !

Date prévue de sortie : le 3 mai 2011 !

Jetprofiler

Cet outil est une vraie petite merveille. Un bon monitoring de son Mysql, rien de tel.

Comme expliqué dans mon précédent Post, le problème de mysql c’est qu’on ne peut pas le faire grossir proprement. En fait au dela de 4 cores, c’est inutile voir nuisible. Donc on multiplie les serveurs. Même si Magento ne tape pas très intensément sur la DB (en général) c’est parfois un des points de contention.

Une implémentation particulièrement complexe au niveau SQL peut aussi provoquer des surcharges ou une Cron un peu gourmande. Bilan, le Mysql rame et on se demande pourquoi.

Avec Jetprofiler, vous pourrez rapidement trouver plus d’information, qualifier le problème en quelques clics.

Pagespeed Online (by Google )

Alors ce n’est pas exactement nouveau, Google Pagespeed, on l’aime à la maison mais là, c’est le petit plus à la Google.

Après le plugin pour Firefox, le GT Metrix, on a maintenant un chouette site dédié chez Google à Pagepseed. Rien de révolutionnaire mais c’est très pratique, notamment pour les gens comme moi qui ne sont pas fan de Firefox, car c’est en ligne. Mais en plus, c’est directement linké au niveau de la KB de Google et CA, c’est sympa.

On ne sait pas ce que c’est que le Defer Javacript blablabla ? Eh ben on clic sur le lien « learn more » et c’est expliqué, merci Google. Allez, un petit exemple :

http://pagespeed.googlelabs.com/#url=www.nbs-system.com

Mytop (mysqltop)

Aussi simple que possible, Mytop, c’est comme le top d’unix mais pour Mysql.

Voila, tout est dit, un petit outil CLI (Command Line) pour permettre de monitorer en un clin d’oeil son Mysql. Ca ne va pas faire le même boulot que Jetprofiler mais c’est light et c’est déjà pas mal. http://jeremy.zawodny.com/mysql/mytop/

Innotop

Dans la série « top est notre ami », innotop, ca parle, ca parle… de Top pour innodb. XAPRB nous délivre son outil plus avancé que mytop, bien plus avancé même, mais c’est un bonheur car pour les amoureux de la command line, il y a tout ou presque.

http://www.xaprb.com/blog/2006/07/02/innotop-mysql-innodb-monitor/

Atop

Désolé, ca doit être le chocolat de paques, je fais une petite fixation sur les top en ce moment. Atop, c’est comme top, mais en plus sympa. Les process sont mieux triés, le package est disponible en debian stable, alors comment parler de trucs qui font des top sans parler d’atop ?

écrit par Philippe Humeau \\ tags: innotop, jetprofiler, magento, mytop, nitrogento, optimisation

Le coup du mailing…

Alors voila…

Imaginons que la cellule marketing d’un client décide unilatéralement d’une super offre marketing. (ca n’arrive jamais rassurez vous, c’est dans un monde imaginaire)

Elle envoie un gros mailing pour soutenir le feu mais… Oublie de prévenir l’IT ou son hébergeur (pareil, c’est totalement utopique, toute ressemblance avec des faits réels serait fortuite). Forcément, le site monte dans les tours.

La solution

L’hébergeur et le DSI détecte le problème et se mettent d’accord, on lance trois machines en Cloud et là, le problème est résolu Merci Extend To Cloud.

Les ventes marche, le client est content, on va tous manger, satisfait de ce devoir accomplit.

Le vrai drame

Quand tout à coup… Entre en scène M. X et il appuie sur le bouton « Flush Magento cache », sans raison particulière, juste pour être sûr, parce que dans le doute, l’humain curieux explore tout son potentiel de liberté et que c’est aussi un peu cela le fameux « développement personnel », cliquez là où on veut, quand on veut !

Alors là, forcément, c’est pas la même…

Les serveurs ne disposent plus de leur cache, le drame arrive inexorablement. Une plateforme sans son cache chaud (hot cache) est 2 à 3 fois moins performante. Bilan, les utilisateurs en surfant vont petit à petit réchauffer le cache et générer les pages statiques mais ca demande de la ressource, le système rame.

Le drame « visuellement » parlant

Sur le Graph ci-dessous, lié au CPU de la machine qui sert la base de données, la barre nommée 1 montre le début du mailing et la barre nommée 2 montre le début du vidage de cache. (bien sur c’est un graph totalement hypothétique vous l’aurez compris)

Clairement, durant le mailing, on monte en charge mais ca tient bien. Dès que le bouton magique est pressé, la machine consomme 2 à 3 fois plus de CPU et se met à ramer.

La Conclusion

Si je ne l’ai pas dit cent fois, je ne l’ai jamais dit, mais informer, c’est aussi répéter :

• On ne vide JAMAIS le cache en production sans raison
• On ne vide JAMAIS le cache lors d’un pic de trafic type solde ou d’un mailing
• On ne met jamais un nouveau site en production avant un pic (ce qui implique un vidage de cache)
• Faire du développement personnel ne passe pas forcément par le fait de cliquer sur tous les boutons et particulièrement sur le bouton « Flush Cache »

D’une manière générale, avant d’appuyer sur le bouton magique qui provoque l’armaggedon, on en discute, on se pose la question de pourquoi on le fait, on vérifie si c’est indispensable, si c’est le seul moyen et dans le doute on en le fait pas.

Ce n’est pas une solution magique mais une solution de dernier recours. Un site en « cold cache » c’est atrocement lent pour les visiteurs et atrocement lourd pour les serveurs. J’ai même vu des setup ou les gens vident les caches en Cron toutes les heures, d’autres où sont lancé des réindexation de base de données plusieurs fois par jour…

Tout cela contribue à tuer les performances et là, pour le coup, Magento n’y est pour rien et n’y peut rien.

écrit par Philippe Humeau \\ tags: cache, flush, magento, mailing, pic, trafic

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.

Où

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: magento, minify, nitrogento, optimisation, performances, sprite