oct 20

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: , ,

juin 24

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: , ,

avr 27

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: , , , , ,

avr 12

Bon, après maintes tentatives de faire des gros articles de synthèse, j’ai 20 brouillons et ca fait deux mois que je n’ai pas publié. Du coup, retour aux sources et aux bonnes pratiques, un petit article simple pour se remettre en jambes.

Firefox, on l’aime ou pas, mais on ne peut pas le quitter


Et personnellement, je suis de ceux qui n’aime pas. J’ai toujours trouvé ce browser lent, insupportable dans sa méthode de mise à jour et blindé de memory leaks. Bon après, il ya une position de principe et au bureau, on lance pas un troll par ci par là, on en a un élevage.

Alors forcément, les browsers et leurs capacités, c’est un sujet récurrent. J’utilise Opera comme navigateur pour certains aspects comme la légèreté, le groupement de tab, le cache hyper efficace, même en cas de restart du browser et les back qui évite de perdre un post au complet.

Chrome à la maison car il est rapide et agréable, simple comme on aime. et … Firefox, car je n’ai pas le choix. Le nombre et la qualité des extensions font de ce browser une plateforme professionnelle incontournable.

Depuis la version 4, c’est  un peu différent. Le navigateur s’est beaucoup amélioré, notamment en performances, ca devient presque un plaisir de bosser avec.

Les extensions, la force incontournable de Firefox


Et c’est bien le sujet de ce post. La capacité incroyable de Firefox de s’étendre. Alors maintenant qu’on vit de nouveau ensemble avec ce navigateur, parlons de ses extensions incontournables, selon moi.

SENSEO

Surveiller sa SEO dans une page précise en tapant une expression directement, c’est possible. Ca s’appelle SenSEO et c’est juste incontournable. Simple, efficace, on en rêvait, sensationnal SEO l’a fait.

Il analyse et fournit les conseil en une fois, c’est tellement beau…

FIREBUG

Forcément, si je n’avais droit qu’à une extension, je prendrai celle-ci. It’s the mother of all extensions ;) Ca permet de vérifier tout ce qui touche à une page web ou presque, des composants chargés aux timings, du javascript au contenu du DOM, tout sur tout ou presque et en plus de nombreuses autres extensions s’appuient dessus. Indispensable, légendaire, une partie du succès de Firefox repose sur ce seul plugin qui a su se rendre indispensable aux développeurs.

YSLOW & Pagespeed

Yslow et Google page speed reviennent souvent dans mes articles. GTmetrix.com permet d’avoir les deux en ligne, se sauver et comparer les résultats mais la version extension est pratique aussi. Pagespeed.googlelabs.com permet aussi de faire l’analyse en ligne avec les liens vers la DB de connaissance Google Labs, toujours utile.

Bref, les deux plugins analysent vos pages à la recherche d’axes d’amélioration et croyez moi, avant d’obtenir le saint Graal (100%/100%) vous avez quelques nuits blanches en vue. Mais les deux fournissent une tripotée d’informations utiles en terme d’optimisation.

WAPPALYZER

Alors ? En un coup d’oeil, c’est un magento ou un prestashop ? Derrière c’est un Nginx ou un Apache ? Tout ca et plus en survolant le plugin de votre souris, c’est possible. Wappalyzer vous donne toutes ces indications car il monitore vos pages chargées et analyse le contenu et les réponses du serveur pour déterminer tout cela pour vous. Simple mais dramatiquement utile.

Et hop, je vois que mon site est servit par un Apache, utilise Jquery a le tag Google Analytics et tourne sous WordPress. La classe ! (bon pour le cas de mon site, je le savais déjà :) )

NAGIOS CHECKER

Sur l’exemple du dessus, vous voyez un N noir avec NBS 47 en Jaune et NBS 3 en rouge. Ce sont les alertes Nagios de nos sondes de supervsions. L’avantage c’est qu’on a pas à être en permanence sur la page Nagios, on peut juste avoir le plugin et en passant la souris au dessus, voir ce qui se passe en alerte et en informations :

PS : 3 services en erreur et 47 en warning, ca peut paraitre beaucoup mais sur 650 sites, ce n’est pas énorme en fait. En l’occurence 2 sites ont dépassés 90% de disques alloués et 1 est en charge critique sur son Mysql. Les autres ont des warning divers, charge CPU/RAM etc.

Bar WEB DEVELOPPER

C’est un outil utile. Nettoyage des cookies pour un site ou pour tous, entourer les frames ou les titres H1/H2, détailler les scripts, forms, images, CSS, tout y est. C’est une formidable toolbox, très légère et très très complète. Must have si vous développez, tout aussi indispensable que Firebug, c’est dire !

GOOGLE TOOLBAR

Nous voila au dernier mais il est toujours aussi utile et appréciable, ne serait-ce que pour les raccourcis vers les services Google ou encore le PageRank. La vieille bar est toujours aussi agréable et discrète, utile et configurable.

Pour les alergiques à Firefox


Beaucoup de Bookmarklet (petit Javascript que vous cliquez quand vous êtes sur une page Web pour lancer une autre page ou un autre service) font un bon boulot. Les Yslow et Pagespeed peuvent s’utiliser depuis le Web.

Les bookmarklet, c’est tout simplement génial. Le site ici en référence un paquet, parmis lesquels j’ai fais un raccourcis sur : URL shorten, Download as PDF,  German to English, GTMetrix test, etc…

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

août 23

Test de charge de son serveur de E-commerce

Dans le cadre d’un benchmark de site Web, de test de charge pour être plus précis, que faut il prendre en compte et pourquoi ? Que ce soit un benchmark de Magento  ou de tout autre Framework / site, il faut le bon outil et surtout la bonne échelle.

Mesurer c’est une chose, mesurer utile ou interprétable, s’en est une autre. La seule mesure qui compte au final, c’est la satisfaction de l’utilisateur qui surf sur le site concerné.

En l’occurrence une échelle de cette satisfaction existe, l’APDEX.

Le but de cet indice est de mesurer, dans un temps donné, combien d’utilisateurs ont eu un temps de réponse satisfaisant. Dans cette chaine, tout est compté, la charge que le site impose au serveur, le temps d’acheminement des paquets, l’affichage de la page etc.

Autrement dit, si je fixe à 2,5 secondes le temps d’affichage optimal pour un site, combien d’utilisateurs vont pouvoir surfer en même temps sur la machine avant que 1 d’entre eux ait un temps supérieur à 2,5 secondes ? Combien vais-je en accueillir avant que 5% d’entre eux ait une page en plus de 2,5s ?

l’APDEX comprend 4 niveaux :

  • satisfied
  • tolerating
  • frustrated
  • inacceptable

c’est donc bien une échelle « user centric ». Le but est de satisfaire l’utilisateur ou tout au moins de ne pas l’irrité. Si l’on fixe la zone de satisfied à moins de 2,5 secondes, la zone de tolérance va de 2,5s, la zone de frustration sera à 10s (4 fois le temps de tolérance) et au delà on est dans l’inacceptable.

Formule de l’APDEX

APDEX = ((nombre de satisfaits) + 0,5*(nombre des tolérants)) / total

(avec le nombre de frustrés = 0)

Si on reprend nos hypothèse et qu’on prend un groupe de 100 tests, mettons que 80 sont sous la barre des 2,5s, 20 sont entre 2,5 et 10 et 0 sont au delà de 10, le coefficient APDEX est de :

(80+20/2)/100=0,9

Se placer sur l’échelle

A 1, tout le monde est satisfait, entre 0,94 et 1, vous êtes dans l’excellence, de 0,85 à 0,94, vous êtes bon, de 0,7 à 0,85 vous êtes honnêtes. de 0,5 à 0,7 c’est mauvais, en dessous de 0,5 c’est la zone de l’inacceptable.

Dans notre exemple au dessus, un APDEX à 0,9 nous donnait 80% d’utilisateurs en zone de satisfaction, 20% en zone de tolérance.

Mesurer cet indice

L’outil Funkload, en dernièreversion utilise cette classification Apdex pour donner des rapports de tests de charge très complet. Une fois que vous avez préparé vos scénarii, il s’occupe de charger la machine jusqu’à ce que l’indice APDEX passe sous une certaine valeur. Une fois cette valeur atteinte, vous avez un nombre d’utilisateur simultanés.

Vous pourrez ainsi facilement mesurer la rapidité de votre site mais en condition réelle. Avec un utilisateur simultané, vous aurez surement des temps de chargements sous la barre de la seconde mais un serveur et son site sont fait pour la vie réelle, pour accueillir des milliers de visiteurs par jour.

Il existe prêt de 30 outils différents à ce jour pour mesurer cet indice mais je vous recommande très fortement Funkload qui permet de faire cela en parallèle d’un test de charge avec des scenarii.

Ordre de grandeur pour Magento

Par exemple, sans Reverse Proxy (RP), avec un serveur de base (bi quadcore 5420 / 8 go), bien configuré et optimisé, sous Magento 1.4 CE, avec un site correct devrait vous amener entre 150 utilisateurs simultanés, tous sous la barre des 2,5 secondes, avec un APDEX à 0,95. (95% des utilisateurs en zone de satisfaction, 5% en zone de tolérance)

Toujours sans RP, un gros molosse (bi hexacore 5670 / 8 Go) devrait vous amener à ~250 utilisateurs sous la barre des 2,5 s avec un APDEX à 0,95. (95% des utilisateurs en zone de satisfaction, 5% en zone de tolérance)

Un mono Quad core AMD 2382 (toujours sans RP), vous amène à 4s pour 150 utilisateurs.

Seulement 100, 150, 200 ? Oui, mais simultanés et sans l’aide d’un rproxy ou du full page cache pour les versions Enterprise de Magento (EE) !

Funkload

Voici quelques captures d’écran de Funkload qui vont vous permettre de mieux comprendre le fonctionnement de l’utilitaire et ce qu’il produit comme rapport :

Apdex spps
Sur cette capture, on voit, en haut, le nombre de SPPS (Successfull page per second) et l’échelle du nombre de CU (Concurrent Users), de visiteurs simultanés. Juste en dessous, le graphique suivant montre l’indice Apdex, la barre verte montre un apdex de 0,95 à 20 utilisateurs simultanés (hors cache, hors rproxy etc…)

CUIci, le graph montre le nombre de CU et le temps d’attente de chacun. A 40 CU, on a un temps de génération des pages de 2,5 secondes au minimum, 3 pour 90% des visiteurs.

Vous pouvez trouver l’outil Funkload sur le site de son auteur M. Delbosc : http://funkload.nuxeo.org/

Un grand bravo à Nuxeo qui porte haut les couleurs de l’opensource et de la qualité dans ce domaine, une entreprise Française en plus !

Conclusion

Ce que nous cherchons tous à savoir c’est : combien d’utilisateurs puis-je accueillir dans des conditions optimales avec mes serveurs ? La réponse est maintenant à portée de main grâce à un indice représentatif de la qualité de la session de surf : l’APDEX et un outil de mesure et de test de charge : Funkload.

En général, on a deux mesures de ce que peut accueillir un serveur, une mesure en visiteurs uniques par jour et/ou l’autre en visiteurs connectés simultanément. Évidemment, vu le type de mesure Funkload, la deuxième est beaucoup plus réaliste.

Ceci étant, peut de personne peuvent exprimer leur besoin en visiteurs connectés simultanément alors que presque tout le monde sait dire combien il accueille de visites par jour. Du coup, la passerelle entre les deux n’est pas forcément aisée et elle est approximative.Les pics sont bien représenté dans les connexions simultanées mais pas dans un nombre de visiteurs unique par jour.

Disons si on devait donner un ordre d’idée, pour du Magento, le ratio entre les deux serait de 150 utilisateurs simultanés en moins de 2,5s avec un apdex de 0,9 correspond globalement à ~35 000 visiteurs uniques par jour.

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

juil 29

Aujourd’hui, un guest nous propose un article.
Aymeric de l’agence DnD nous explique comment on peut faire de l’optimisation progressive.
Rien à voir avec le fait d’y aller petit à petit mais plutôt d’envoyer des pages de plus en plus complètes/complexes en fonction des capacités des navigateurs clients.

Optimisation dʼintégration par la technique de lʼamélioration progressive.

Si je vous parle dʼoptimisation web, vous me citerez très certainement les chargements parallèles, les CDN, les sélecteurs CSS efficaces, la réduction du poids des images, etc …

Lʼapproche est bonne, mais je répondrai ceci :
« Optimiser globalement son site cʼest bien, lʼoptimiser pour les différents navigateurs cʼest mieux»

Dans cette article, jʼexpliquerai une technique de conception de site web qui s’avère très efficace pour lʼoptimisation, la stabilité et la pérennité de votre site : cela se nomme lʼamélioration progressive.

Deux techniques de conception web

Il existe deux techniques pour la création de sites web optimisés :

La première sʼappelle « lʼamélioration progressive » et la seconde la « dégradation élégante ».

Elles cohabitent toutes les deux depuis longtemps et sont utilisées par la majorité des acteurs du web (agences web, free-lances, …), et ce, parfois sans même sʼen rendre compte.


Voici une brève définition :

  • La dégradation élégante est le fait de construire dʼabord son site en fonction des navigateurs les plus performants, puis de se concentrer ensuite sur la compatibilité avec les anciens navigateurs.
  • Lʼamélioration progressive cʼest lʼinverse. On se base dʼabord sur un ancien navigateur puis on rajoute des couches techniques successives plus poussées et plus abouties supportées par les navigateurs les plus récents.

Mais laquelle utiliser ?

La plupart privilégierons la dégradation élégante car cʼest à leurs sens la technique la plus simple à mettre en place et la plus utilisé. En effet, nous avons probablement tous déjà entendu un jour : « Les gars, jʼai fini dʼintégrer le site sur FireFox, jʼattaque maintenant le débug sur ce bon vieux IE6»

Cependant cette technique nʼoffre que très peu de souplesse, car il est nécessaire de partir de votre « bijoux » technique puis de le «démolir» petit à petit tout en corrigeant les différents bogues afin quʼil soit compatible avec les anciens navigateurs.

Petite métaphore pour appuyer mes propos

« Faut-il forcément sʼobliger à regarder une cassette VHS sur un écran Full HD sous prétexte quʼelle est compatible avec le magnétoscope de notre Mamie ? »

Nʼest il pas préférable de visualiser son film en Blu-Ray et se procurer une cassette VHS en parallèle pour que notre chère Mamie puisse regarder le film sur son magnétoscope auquel elle tient temps ?

Oui cela demande dʼavoir 2 versions du film, une en DVD Blu-Ray et lʼautre en VHS… et oui cela demande plus dʼinvestissement et plus de temps, mais il sʼagit du seul et unique moyen pour que personne ne soit exclu tout en ayant un média qui convient avec notre support.

Vous lʼaurez compris, je vous invite grandement à utiliser la technique de lʼamélioration progressive .

Pour en savoir plus sur ces techniques, je vous invite à lire ce très bon article.

Il date un peu mais reste dʼactualité : http://www.pompage.net/pompe/degradation-elegante-et-amelioration-progressive/

Exemple pratique

Voici la partie la plus intéressante, un exemple de la technique dʼamélioration progressive sur un bouton. Vous allez vous apercevoir que le gain de puissance est incroyable.

Voici notre bouton :
Capture

Première étape : Scindez les systèmes.

Ce bouton comporte des arrondis. Quels systèmes permettent de le faire de façon légère et optimisée ?

  • FireFox 3, SAFARI 4, CHROME gèrent déjà les bordures arrondis et les ombres grâce à leur moteurs graphiques (webkit, moz, …)
  • IE ne le gère pas. Surprenant non ? :)

Deuxième étape : Créer un code pour chaque système.

Pour les anciens navigateurs :

a.button {
background: transparent url('bg_button_a.gif') no-repeat scroll top right;
color: #444;
display: block;
float: left;
height: 24px;
padding-right: 18px;
text-decoration: none;
}
a.button span {
background: transparent url('bg_button_span.gif') no-repeat;
display: block;
line-height: 14px;
padding: 5px 0 5px 18px;
}

Pour les nouveaux :

a.button {
background-color: #DDD;
border: 1px solid #000;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
-khtml-border-radius: 5px;
border-radius: 5px;
color: #444;
display: block;
float: left;
height: 24px;
line-height:24px;
padding: 0 10px;
}

Troisième étapes : Constatez lʼoptimisation avec le même rendu sur les tous les navigateurs :

  • Pour les anciens navigateurs, vous aurez un bouton construit à partir de 2 images de fond (2,3ko).
  • Pour les navigateurs récents, vous nʼaurez juste que quelques lignes de codes (0,6ko).

Appliquez ce que nous venons dʼeffectuer avec ce bouton à lʼensemble de vos éléments web. Vous obtiendrez alors un site avec peu dʼimages, un poids pour chaque page très faible.

Conclusion

Maintenant, imaginez un site sans images, avec des templates web entièrement développés en code, facile à gérer, des pages ayant un poids ridicule, et ce, sans jamais perdre en qualité.

Ce monde est déjà à nos pieds avec lʼutilisation du CSS3 et du HTML5… Pour ce faire, il vous faudra ajouter de manière progressive une couche supplémentaire à vos sites et en apprécier le gain gagné sur votre dernier navigateur… :)
Par Aymeric Aitamer, Agence DnD.

écrit par Philippe Humeau \\ tags: ,