Beaucoup de principes sont généraux à tous les frameworks, qu’ils s’agissent d’un site Magento, Prestashop, WordPress, Drupal, etc… Certains Framework ou plugins de ces solutions vous aident nativement à le faire, d’autre n’ont pas cette possibilité ou cette richesse en stock.

J’ai récemment refais le site de NBS System (ma société) de A à Z avec nos amis de l’agence DnD et forcément, on s’est un peu intéressés à l’optimisation. C’est un chemin complexe mais passionnant alors autant vous faire partager quelques trouvailles dans le domaine.

Je ne reviens pas sur le pourquoi, optimiser c’est bien, améliorer l’expérience utilisateur c’est bien, avoir un meilleur référencement naturel car on charge vite, c’est bien. De toute façon vous surfez sur un Blog, il faudra bien justifier cela à votre boss un jour donc on va dire que c’est pour le bien d’Internet et la préservation de la bande passante.

Après en société, vous pourrez faire les malins et expliquer qu’en optimisant votre site, vous avez participer à éviter l’Exaflood, ca ne fait pas tomber les femmes mais coté entretient d’embauche, sur un malentendu, vous forcerez l’admiration.

Comment Analyser

Nos deux amis : Yslow et PageSpeed. Ces deux plugins fonctionnent sous Firefox et vous donnent un point de vu sur ce qui est propre, bien fait et ce qui ne l’est pas. Pagespeed, celui de Google, est plus nouveau et un poil plus complet, il tourne évidemment aussi sous Chrome. Yslow est celui fournit par Yahoo depuis des années, il est très intéressant également, personnellement, j’utilise les deux.

Je vous conseil aussi le site websiteoptimization qui vous donnera aussi de préciseuses infos. Evidemment, passer sans erreur le XHTML validator est important également, même si c’est pas toujours simple.

En complément, je me dois de citer l’excellent site www.gtmetrix.com. Pour ceux qui comme moi utilisent Opera ou qui ont un browser exotique et qui n’ont pas nativement ces plugins, c’est bien utile d’avoir à la fois Yslow et Pagespeed au même endroit, dans une même page.

Pagespeed :

Yslow :

GT Metrix :

Lire les résultats

Evidemment le but est atteindre le rating maximum, soit A/A ou 100%/100%.

C’est pour ainsi dire impossible donc si on peut aller à une note très intéressante, ca sera déjà pas mal. Ceci va en plus réduire le temps de chargement de la page et donc nous faire passer sous la barre d’1,5 seconde et donc améliorer la façon dont nous considère Google.

Dans l’immédiat, on voit que Pagespeed à un peu plus de critères mais on retrouve 70% de points communs soit une forme ou une autre alors je vais les grouper par types.

Pagespeed : « Parallelize downloads across hostnames »
Yslow : Use Cookie-free domains
Pagespeed : Serve static content from a cookieless domain

C’est quasi comparable, dans le principe il s’agit de permettre aux browsers qui viennent de télécharger vos contenus de sites depuis plusieurs serveurs distincts afin de leur permettre d’établir plus de connexions simultannées. En gros, pour ne pas saturer les serveurs, les browser ne s’authorise que 6 à 15 connexions vers un même serveur, c-a-d qu’ils ne téléchargent que 6 à 15 éléments simultanéments et attendent pour demande les suivants que des connexions se libèrent.

C’est paramétrable du coté du client, sur le navigateur mais on ne va pas demander à chacun de modifier son paramétrage de navigateur donc il vaut mieux utiliser plusieurs serveurs, quand cela est possible, pour servir le contenu, notamment static. Ici, seul le hostname compte, vous pouvez avec le même serveur physique derrère un www1, www2 etc…

Avoir 4 serveurs qui distribuent le contenu va permettre aux navigateurs d’aller beaucoup plus vite pour récupérer les contenus. Un petit regret ici, il aurait été plus simple d’intégrer un variable sur le nombre de thread concourrant accepté directement dans le handshake http 1.1. Ca aurait permis d’accélérer en basse charge et de diminuer pendant les pics. On peut aller plus loin aussi en servant depuis plusieurs endroits, sur un domaine différents « cookieless ».

Ce n’est pas très compliqué à faire en réalité. Le plus simple c’est d’enregistrer un nom domaine différent de celui du site, par exemple static-nbs-system.com et de mettre un CNAME dans la zone DNS qui pointe sur l’enregistrement A du site (en l’occurence nbs-system.com). Ensuite on configure le service web pour fournir les ressources statiques depuis ce nouveau domaine, on interdit de poser les cookies sur ce domaine et dans les pages web on appelle les ressources statiques sur ce domaine. On peut bien sûr reproduire le schéma avec n host sur ce nouveau domaine, static1.blablabla, static2.blablabla etc…

Ca à l’air bien sur le papier mais si le framework le gère pas, il va falloir éditer des fichiers de config, des fichiers php ou HTML ou encore jouer de la commande sed pour automatiser le remplacement de l’url. (pour sed, vous pouvez voir l’article ici)

Je ne sais pas si ca à une influence sur la SEO par contre. Vu que le nom et l’URL des ressources statiques participe à la SEO on m’a dit, je ne sais pas l’impacte.
Faible je suppose vu que ce sont des plugins de moteurs de recherche qui conseillent ce mouvement… Un pro de la SEO pour m’éclairer ?

Yslow : « Use a Content Delivery Network (CDN) »

L’idée est un peu la même mais à une petite nuance prêt. Yslow conseil l’usage d’un CDN de manière absolu, un qui soit connu pour le reprérer. Pagespeed lui conseille de multiplier les sources servant les fichiers. L’idée de fond reste proche, servir le plus vite possible les éléments, depuis des sources spécialisées. Soit vous prenez un CDN connu (Akamai, limewire etc…) soit votre prestataire à le sien, soit vous en prenez un gratuit.

Dans les deux derniers cas, Yslow ne connaitra probablement pas votre CDN et vous devrez malgré tout trainer une mauvaise note sur ce sujet… Ca n’empêche pas d’avoir un A cependant car pour Yslow, c’est un point moyennement important. Et puis soyons honnête, avoir un CDN (Content Delivery Network) ce n’est utile que pour des sites qui servent à destinations de plusieurs pays distants, dans la majorité des cas, un serveur de ressources statiques suffit.

Yslow : « Add Expire headers »,
Pagespeed : « Leverage Browser Caching »

Ca joue beaucoup, ca compte beaucoup et, bonne nouvelle : c’est facile à faire !

Avec Apache, un petit tour dans la configuration, on ajoute le mod Expire et le mode Etags et on met les lignes de configurations suivantes :

LoadModule expires_module /usr/lib/apache2/modules/mod_expires.so
ExpiresActive On

FileETag MTime Size

<IfModule mod_expires.c>
 ExpiresActive on
 ExpiresByType image/jpg "access plus 6 months"
 ExpiresByType image/jpeg "access plus 6 months"
 ExpiresByType image/gif "access plus 6 months"
 ExpiresByType image/png "access plus 6 months"
 ExpiresByType text/ico "access plus 6 months"
 ExpiresByType image/ico "access plus 6 months"
 ExpiresByType image/icon "access plus 6 months"
 ExpiresByType image/x-icon "access plus 6 months"
 ExpiresByType application/x-shockwave-flash "modification plus 6 months"
 ExpiresByType text/css "access plus 1 week"
 ExpiresByType text/javascript "access plus 1 week"
 ExpiresByType text/html "modification plus 1 week"
 ExpiresByType text/xml "modification plus 2 hours"
 ExpiresByType image/vnd.microsoft.icon "access plus 6 months"
 ExpiresDefault "access plus 1 week"
 #Header set Cache-Control "max-age=86400, public"
</IfModule>

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf)$">
 Header set Cache-Control "max-age=290304000, public"
</FilesMatch>

Voila, on a indiqué à Apache qu’on calculait la fraicheur d’une ressource en fonction de la date d’accès et de sa taille  (FilteEtag MTime  Size) et ensuite on lui a donné, par type de ressources, un temps d’expiration du cache. En résumé, quand votre navigateur récupère une donnée, il a le droit de la garder 6 mois si c’est un jpg par exemple, 1 semaine si c’est un javascript.

Evidemment, il faut le paramétrer en fonction de votre site et de la fréquence à laquelle vous mettez vos éléments à jour. Enfin, autre format, les 3 dernières lignes mettent une expiration à 480 semaines par défaut sur les ressources du type cité.

Si vous développez, il est fortement conseillé d’avoir une préproduction sur laquelle vous n’avez pas ces lignes, afin d’avoir le résultats de vos modifications instantanément et pas 480 semaines plus tard

Les deux plugins considèrent, à juste titre, que c’est un point important.

Yslow : Compress components with Gzip
Pagespeed : Enable Gzip compression

Il peut y avoir un peu débat sur celui-là, et encore. En gros le débat serait que sur un serveur dont le CPU est chargé, faire du Gzip en plus, ca aggrave le problème… Oui et non. Déjà, l’algorithme Zip est ultra rapide et optimisé, ca prends très peu de ressources à processeur moderne. En plus, servir plus vite c’est aussi diminuer sa charge de travail quelque part (on peut traiter plus de monde).

Coté débat, nous chez NBS, en matière de serveur E-commerce, on a tranché, c’est oui.

<IfModule mod_php5.c>
   php_flag zlib.output_compression on
</IfModule>

<IfModule mod_deflate.c>
 SetOutputFilter DEFLATE
 AddOutputFilterByType DEFLATE text/*
 DeflateFilterNote ratio
# Patch pour les navigateurs qui ne supportent pas
 BrowserMatch ^Mozilla/4 gzip-only-text/html
 BrowserMatch ^Mozilla/4\.0[678] no-gzip
 BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Humm compresser les images, ce n'est pas utile, loin de là
 SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
 SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
 SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
</IfModule>

Bon, c’est assez simple et explicite, on compresse tout ce qui est textuel, on désactive pour les vieux Mozilla 4 et les IE, on ne compresse pas les images.

Ca réduit bien les transferts mine de rien :

Type Uncompressed Compressed Win doc / HTML 44,5 14,8 67% js 25,1 10,4 59% js 57,2 19,7 66% js 0,9 0,4 56% js 90,4 29,8 67% js 17,4 8,1 53% css 30,9 6 81% économie 177,2 Ko 33%

C’est tangible et appréciable, ca économise de la bande passante des deux cotés, c’est tout bon !

Yslow : Minify Javascript and CSS
Yslow : Remove duplicate Javascript and CSS
Pagespeed : Combine external JavaScript
Pagespeed : Minify Javascript
Pagespeed : Removed unused CSS
Pagespeed : Minify CSS
Pagespeed : Combine external CSS

Okay, ca fait beaucoup d’un coup mais c ‘est la même logique derrière.

Le principe de fond : on regroupe les CSS et les Javascript en deux fichiers au lieu de 15, on les nettoye des bouts de codes ou expressions non utilisées, on les « minify » (on les densifie, on enlève les espaces et les choses inutiles).

L’idée est bonne mais ca fait un code peu maintenable, alors le conseil du pro : on fait son site sur la préproduction et on se fait un script bash de mise en production qui fait le ménage et compacte  le tout au moment de la mise en production. Comme cela, on a une préproduction qui reste efficace à maintenir avec des fichiers lisibles et un production optimisée.

Pour réaliser ces optimisations, deux possibilités voir même beaucoup plus. Pagespeed à la gentillesse de fournir certains fichiers optimisés directement depuis le plugin. On le sauve, on le met sur la production et hop, c’est finit. Pour optimiser ses CSS on a aussi le site cssoptimiser ou le cssclean. Bref ce ne sont pas les outils qui manquent. Pour les combiner, ca dépend de la technologie, sous Magento on a Fooman speedster, sous WordPress il y a CSS-JS-Booster de mémoire, parfois vous devrez tout simplement le faire à la main.

Evidemment enlever le code inutile des JS et/ou des CSS, c’est un impératif.

En réduisant le nombre de fichiers, on réduit le nombres de requêtes HTTP, on économise des transferts, de l’overhead, bref, là encore c’est du tout bon.

Personnellement, j’ai massivement utilisé les fichiers directement issus de Pagespeed quand il m’en proposait, c’est parfait.

La plupart du temps, ces modifications sont considéré comme importantes par les plugins.

Yslow : Avoid CSS expressions
Pagespeed : Use efficient CSS Selectors

J’ai regroupé ces deux là car ils touchent aux CSS et à leur optimisation. C’est un réel enjeu car les navigateurs se débrouillent plus ou moins bien avec les CSS et cela peut engendrer des délais du coté de l’utilisateur.

Yahoo Yslow nous dit d’éviter les expressions CSS, ce qui permet de changer dynamiquement un CSS si le browser est redimensionné par exemple. Le problème c’est que ces expressions sont appelées tout le temps, pendant la génération de l’affichage, au redimensionnement, parfois pendant le scrolling. Du coup ca charge un maximum le navigateur client. Ceci étant tous les frameworks ou presque évite ca comme la peste, vous ne devriez pas avoir de soucis avec. Sinon, il faut s’en passer et réécrire les portions du CSS qui utilisait ce système.

Google Pagespeed nous indique pour sa part qu’il est préférable d’utiliser des CSS selector efficaces. Ouiiiiiii, c’est à dire qu’on est pas contre, mais c’est quoi la différence entre un bon et un mauvais CSS selector ? C’est comme la chasse. Le bon chasseur, il voit… okay… on reprend.

Le but c’est d’éviter d’appliquer une clef de sélection peu efficace à un grand nombre d’éléments car cela pénalise les performances du navigateur. Mais cela va plus loin c’est plus une connaissance générale de la grammaire CSS qu’il faut avoir.

Par exemple, il vaut mieux :

• utiliser une classe pour appliquer un style à de nombreux élements
• privilégier le mécanisme d’héritage
• utiliser des règles spécifiques
• utiliser des class et ID plutot que des sélecteur de type Tag
• éviter les qualificateurs redondants (ex : ID selectors par class et class selectors qualifiés par un tag selector)
• éviter les sélecteurs descendants, surtout pour ceux qui pointe des ancêtres redondants (par exemple bidy ul li a {…} est un sélecteur redondant puisque tous les éléments sont des descendants de ce tag)
• utiliser des sélecteurs de class plutot que des sélecteurs descendants
• si vous devez utiliser un selecteur descendant, préférez un « child selector » qui nécessitera moins d’interprétation.
• dans le cas d’IE, évitez les :hover pour les éléments qui ne sont pas des liens
• si vous utilisez :hover sur des éléments qui ne sont pas des ancres, testez là sous IE 7 & 8 pour être sur que ca fonctionne.

Ok j’ai fais mon possible pour le traduire de l ‘anglais mais ce n’est pas mon domaine non plus alors si vous n’avez rien compris, allez à la source, ici. C’est un métier développeur Web, moi je vous le dis…

Yslow : Avoid HTTP 404 (Not Found) error
Yslow : Avoid URL redirects
Pagespeed : Avoid bad requests
Pagespeed : Minimize redirects

Ne riez pas et surtout vérifiez que vous n’en avez pas. Sur un site normal, en production normal, on ne doit pas tomber tous 3 objets sur un 404, ni même sur un 301 ou un 302. Qu’il y ait du rewriting temporairement pour maintenir une compatibilité, why not, que ce soit les 3/4 des URLs, encore plus vers un autre domaine, c’est  à proscrire.

Les 404, on s’en doute, c’est mal, d’autant plus que c’est surtout votre SEO qui va prendre. Mais les redirections prennent du RTT (pas des vacances, du Round Trip Time, des voyages allers/retours), ce qui ralentit l’ensemble.

Là aussi, c’est important, plus pour Pagespeed que pour Yslow qui tolère les 404 et dégrade moins la note.

Pour trouver vos 404, les google webmaster tools peuvent vous aider, les plugins, dont Firebug vous les donnent, des sites sont aussi disponibles pour vous aider à les trouver. Personnellement, j’utilise Firebug, ca me suffit. (oui ok, je n’utilise pas que Opera, c’est vrai)

Yslow : Do not scale images in HTML
Pagespeed : Specify image dimensions
Pagespeed : Optimize images
Pagespeed : served scaled images

Alors, là on est sur de la logique pure et dure…

Si je prend une image en 800×600, que je la pose sur le serveur et que je l’affice dans du 400×300, j’ai transféré une image 2 fois trop grosse pour rien (en fait 4 fois trop grosse, faite la multiplication). Donc je dois servir des images de la taille de ce qui va être affiché.

Je dois aussi spécifier les dimensions directement si possible (ca accélère le rendu des navigateurs) et bien sur, ne pas les redimensionner par du HTML, ce qui va à l’encontre de la précédente optimisation et aussi du fait qu’on a directement des images de la bonne taille.

Pour ce qui est d’optimiser les images sans pertes de qualité, le plugin fournit tout seul les versions optimisées… C’est pas le bonheur ca ?

Du bon sens on vous dit !

Yslow : Put CSS at the top
Pagespeed : Optimize the order of styles and scripts
Pagespeed : Put CSS in the document head

Le principe de fond c’est de charger les données dans l’ordre le plus efficient. Il faut que le début de la page puisse se charger le plus vite possible pour « visuellement occuper le terrain ». Si les images arrivent en dernier mais que tous les scripts sont chargés, le site est techniquement quasi fonctionnel mais inregardable.

Dans la première demi seconde, on doit donc passer les CSS pour « préparer le terrain », formater la page et commencer à afficher du texte et des images puis faire passer les images nécessaires puis enfin le Javascript.

Une fois la page chargée, c’est rare qu’un utilisateur clic instantanément, il prend le temps de la lire un minimum avant de cliquer, le Javascript peut donc arriver un peu en retard, de même s’il se charge d’une animation, on peut patienter 1 seconde de plus, c’est moins génant qu’une page blanche.

Bon ca tient de la bonne parole inapplicable parfois. Par exemple WordPress continue de charger les JS en début de page en version avant 3.0 (je n’ai pas vérifié sur la 3.0). Sous Magento, selon votre site, vous aurez peut être besoin de certains JS rapidement. Bref, ca se fait bien en général mais le cas particulier est légion.

Yslow : Reduce cookie size
Pagespeed : Minimize request size

Là encore, on essaye de réduire la données « inutilement » transférée.
L’idée c’est d’arrêter de transférer des cookies pour des ressources qui en ont aucun besoin, comme les images.

Chaque cookie par le navigateur transféré va consommer un peu de bande passante et de temps, pour rien et des millions de fois sur un an. Je n’ai pas compté combien cela peut faire en arbre sur un an mais le bilan carbon des cookies inutiles est lamentable. D’une manière générale, réduire la taille des requêtes, des cookies et leur nombre au minimum.

Alors Google et Yslow sont relativement d’accord, il faut servir les fichiers statiques depuis un domaines qui ne pose pas de cookies dans la transaction.

Yslow : Make fewer HTTP requests

Un croustillant celui-là. Ca à l’air anodin mais on pourrait faire un post rien que sur lui…

J’aurais bien fait mon lache et laissé ca de coté si ce n’était pas justifié mais là… On va devoir le traiter, c’est pas un détail.

Welcome to the CSS Sprites world !

Un sprite c’est quoi ? C’est globalement innofensif, c’est une image avec plein de morceau dans laquelle on découpe le bout dont on a besoin à un moment donné pour l’afficher. Oui, jusque là, ca à l’air innoffensif, attendez la suite.

Voici le CSS sprite du site NBS System, sur lequel Aymeric de l’agence Dnd (notre web agency) à sué sang et eau :

Si on résume la chose, c’est une image qui se comporte comme une carte. Quand on a besoin d’un bout de celle-ci, onva taper aux coordonnées X/Y qui vont bien et on on obtient ce que l’on a demandé. L’intérêt c’est qu’au lieu d’aller chercher 50 icones, on prend directement une grosse image, on fait donc 49 transferts http de moins avec toute l’économie d’overhead que ca représente.

Du coup dans son CSS on change son image par :

.blog .widget .header{height:42px;background:url(images/sprite.png) no-repeat 3px -258px;}

Ca n’occupe aussi qu’une socket du navigateur au lieu de 50, ce qui part groupe de 10 impose 5 volées de récupération des données. (voir le paragraphe précédent et le leverage browser cache).

Donc tout cela est merveilleux sauf que notre site, il vient rarement avec des sprites tout fait. Le graphiste lui, il fait des icones, il les fournit à l’intégration qui fait un CSS et du HTML et du coté sprites, il considère plus que c’est des boissons gazeuses.

Alors comment on génère ses sprites ? Deux cas pour démarrer. Soit vous êtes fort chanceux et vous avez évitez la problématique des dégradés et des ombres et ca va considérablement faciliter votre travail. Soit vous avez un beau site mais vous allez y passer du temps à vos sprites…

On peut le faire à la main, avec amour, mais ca prend un peu de temps… Quoiqu’il arrive, il faut passer par le stade préprod / prod, comme pour les compilations de JS /CSS sinon c’est pas facile à maintenir.

Bonne nouvelles : Il existe des générateurs.
Mauvaise nouvelle : Ca marche pas toujours et pas dans tous les cas.

Trois bonnes pistes sérieuses :

• Sprite me : Le plus atypique et très bien pensé. Il marche en bookmarklet, l’avantage c’est qu’il génère les différences à faire dans son CSS en live, c’est bien fait, assez efficace.
• un autre générateur en ligne, très simple mais moins complet aussi je trouve
• un des plus complets : spritegen

Il existe aussi un truc super bien je pense qu’à utilisé Aymeric pour mon site mais ce petit cachotier n’a pas voulu me dire son nom… Peut être une trouvaille ou un développement maison, je vais le cuisiner, n’hésitez pas à envoyer pleinnnnnnn de mails à l’agence DnD jusqu’à ce qu’ils lachent l’info !

En complément : un article assez complet traduit en Français ici. Sous WordPress il y avait Csprite qui était pas mal mais qui n’est plus maintenu… Un autre article pas mal du tout ici.

Un moyen de générer vos CSS sprites avec Photoshop aussi ici.

A l’époque où je faisais une fixation sur les CSS sprites, j’avais trouvé un binaire opensource assez formidable qui permettait de commenter un CSS normal et de le compiler après coup en un CSS utilisant un Sprite, tout en générant le sprite au passage. Top. Mais j’ai perdu la bookmark pour le moment alors dès que je l’ai retrouvé, je corrige ce post, si vous voyez de quoi je parles, postez moi un petit commentaire.

Les derniers points

Yslow : Reduce the number of DOM elements

Les objets DOM (Document Object Model) nécessitent d’être tous chargés et parsés avant que les interprêtations Javascript (notamment) ne démarrent. Donc plus d’objets, plus de taille et donc de transfert, plus de mémoire utilisée, plus de temps de traitement, plus de délai avant que toute la page ne soit prête.

Réduite la taille du DOM est donc important dans une certaine mesure.

C’est d’autant plus vrai que les surfers ont de plus en plus de pages ouvertes en tabs, si tout le monde force en Javascript et pose des DOM énorment, les browsers se tapent des indigestions et … ca rame. C’est une question d’hygiène globale du browser quelque part

Yslow : Make favicon small & cacheable

Parfois, je n’aimerai pas être une mouche chez Yahoo. Celui qui a sortie celle-ci est légèrement « tatillon » quand même, voir dypterophile sodomite à tendance compulsive.

Bon la Favicon, en faire une petite, c’est pas trop dur. Optimisée non plus. Par contre, la rendre cachable, ca a été un poil énervant car Apache n’aimait pas le mime/type ico ou gif/jpg donc ca ne parait jamais dans le module mod_expire…

Très pénible jusqu’à ce que je trouve le type mime des favicons :

ExpiresByType image/vnd.microsoft.icon "access plus 6 months"

Et voila, c’est caché, d’un coup l’Internet va plus vite… ou pas.

Yslow :  Avoid AlphaImageLoader filter

Oui alors si certains sont encore assez téméraires pour tenter d’afficher des images transparentes, style png, dans un IE datant d’avant la version 7, je penses qu’il a d’autres priorité en terme d’optimisation que ce que je racontes là.  Les soins psychiatriques et une URL de download d’Opera, Firefox ou Chrome.

En gros si vous jouer avec de la gif / png transparente, IE ne gère pas ca très bien, au mieux ca le ralentit, parfois ca le fait planter, on a même vu des failles de sécurité grave sur ce sujet…

Donc forcément, il faut éviter de proposer une bouteille de vodka à un alchoolique, là c’est pareil, pas de png transparente pour IE.

Pagespeed : Minify HTML

Alors là, forcément, on s’affronte à un problème. Soit on a un framework (magento, drupal, wordpress etc…) qui fait ca tout seul, bref du php qui génère du HTML, soit on a fait le sien. La deuxième catégorie devient rare et dans la première, sans toucher au core, on a peut de moyen d’action en général.

La plupart des outils proposent un système de templates qu’on peut optimiser mais c’est parfois coton. A voir mais sur le site de NBS par exemple, pour 7,9 Ko à réduire, il me met un malus de 27% sur ce point et me dégrade la note à C… Abusif je trouve mais bon, soit.

Pagespeed : Specify a cache validator

L’idée c’est de donnée la méthode par laquelle on vérifie que la ressource est fraiche ou non. Sous Apache, ca se fait par l’intermédiaire du paramètre :

FileETag MTime Size

Là on précise à Apache qu’on décide que la ressource à changé si soit la date de modification à changée, soit la taille.

Pagespeed : Specify a Vary:Accept-Encoding header

Allez, devinez, c’est encore pour IE… Comme quoi on peut faire un produit ultra pourrit et l’imposer sur le marché. Ca on peut pas enlever ca à Microsoft. Je n’ai rien contre eux sur le fond mais sur le navigateur, ils ont vraiment pourrit le web.

Notre ami IE donc, ne support pas les Vary headers. Du coup, si il trouve dans le header d’une ressource autre chose que User-agent et Accept-encoding, il ne la cache pas… Dans le principe, totalement se passer du Vary header est le mieux.

Pagespeed : Specify a character set early

Dès qu’on précise le character set, le navigateur peut démarrer certaines interprêtation, dont Javascript. Avant il ne sait pas comment interpréter les données, il est donc conseillé de le faire vite. En fait rien ne s’oppose à le faire le plus tôt possible et tous les framework standard le font en général.

Yslow : Make JavaScript and CSS external

Avoir des fichiers séparés pour les CSS et les JS permet de les stocker en cache et de ne pas les transférer dans le HTML à chaque échange ou chaque page. Donc il vaut mieux ne pas mettre son JS et son CSS directement dans le code HTML et faire un include de fichiers externes, c’est beaucoup plus propre et simple.

Yslow : Make AJAX cacheable

En fait sur ce point, ce qu’il faut comprendre derrière le laconique « Make Ajax Cacheable » c’est « Make Ajax requests results cacheable ».

Faire un requête ajax en background pour fluidifier le trafic c’est top mais ne pas stocker la ressource récupérer en cache c’est gacher ce premier transfert, reconsommer de la bande passante, participer activement à la déforestation des ours en pologne, bref, c’est le mal.

Yslow : Use GET for AJAX requests

oUn Get est plus valable qu’un POST car avec un GET on transfert le headers et les données en même temps, ca évite un transfert inutile. Cependant, si vous avez des requêtes un peu longues, IE n’accepte pas les requêtes de plus de 2Ko. Qui a dit « encore IE » ? Pas de dénigrement, on est là pour progresser, tous ensemble, même les browsers qui partent avec de sérieux handicapes de conception.

Les vrais pervers tenteront donc de transférer en GET, des images PNG transparentes de plus de 2 Ko, en laissant le vary-header avec un IE. Là normalement, on a tout bon pour avoir un beau blue screen

Yslow : Reduce DNS lookups
Pagespeed : Minimize DNS lookups

Une résolution DNS prends entre 10 et 100 ms en gros. Pendant ce temps, le browser doit attendre que la résolution se fasse. Si on peut lui éviter d’avoir à résoudre beaucoup de noms et/ou hostnames différents, c’est plutot positif. Cela va aussi à l’encontre des multiplication hostname sur un domaine différents pour paralléliser les download quelque part.

Une fois résolu, la réponse reste en général dans un cache local, on peut donc décemment imaginer que multiplier les hostnames (par exemple 4 statics) est correctement rentable et n’impose pas trop de lookups.

Pagespeed : Remove query strings from static resources

Typiquement ca :

http://www.nbs-system.com/wp-includes/js/jquery/jquery.js?ver=1.3.2

La paramètre « ?ver=1.3.2″ empèche certains proxys (dont Squid notamment) de cacher la ressource.

Pagespeed : Serve resources from a consistent URL

Pour les ressources partagées sur de multiples pages ou sites, il vaut mieux que la référence se fasse par rapport à une unique URL.
Cela permet notamment de ne pas renvoyer de fichier depuis plusieurs endroits différents, provocant des ns lookups d’ailleurs. L’exemple donné par Google c’est que si monsite.exemple.com et tonsite.exemple.com utilise le même JS, autant qu’il soit servit directement depuis un seul des deux sites, comme ca il sera déjà en cache dans le browser quand on ira de l’un à l’autre.

Autres optimisations

D’une manière général, il y a beaucoup d’autres optimisations, plus systèmes celles-ci, j’en parlerai prochainement, peut être directement sur le blog de NBS System. Les reverses proxy, les compilations de noyaux, les optimisations de .htaccess etc…

Mais bon, on a déjà de quoi s’amuser un peu là non ?

Je paye ma tournée au premier qui nous sort son site en A/A, ensuite celui qui nous passe un site Magento en A/A et pareil pour celui qui fait 100%/100% (sans tricher). Ca fera trois tournées mais elles seront largement méritées, chacunes d’elles !

PS : La doc de Google sur ces sujets est excellente, n’hésitez pas à la consulter.

Vous pouvez également lire l’article d’Arnaud ici : http://bit.ly/ban1Pm

Les grandes marques sont de plus en plus présentes sur Internet par l’entremise de leurs sites web marchands. Ces marques sont capables de générer des trafics colossaux sur une journée, tout particulièrement pendant des périodes particulières comme les soldes.

De plus, les grands rendez vous sont souvent les mêmes pour les sites de E-commerce ce qui fait que tous consomment beaucoup de ressources en même temps.

Les trois grands types de ressources consommées pendant ces pics de charge sont les suivants : réseau (bande passante), processeur, RAM.

Que faire lors de ces soldes, lors de ces pics et surtout pour ces grandes marques ?

Passer de 100 000 Visiteurs uniques par jour à 500 000 relève du possible pour ces grands compte. En contrepartie, passer de 3 serveurs frontaux à 15, juste pour des pics temporaires, semble couteux et peu pertinent dans le long terme, sans compter le gachis de ressources.

Le Cloud (computing)

Le cloud computing est une solution technique qui permet l’usage de ressources de type CPU / RAM, Bande passante « au compteur ». Vous payez ce que vous consommer. Il y a un coût rémanent pour l’hébergement de fichiers sur le Cloud mais il est très réduit.

Cette solution de payement à la ressource réellement consommée est donc un moyen très adapté de ne mettre en place des ressources que quand cela est nécessaire et de ne facturer que ce qui est consommer.

Plusieurs Cloud existent, Amazon S3, Rackspace etc…

Du simple C.D.N à l’infrastructure

Le C.D.N veut dire Content Distribution Network. En résumé, les données statiques, images, films, css, html simple peuvent vous être fournit depuis un lieu proche de vous plutôt que depuis l’autre coté de l’océan. Ceci améliore la rapidité de chargement mais également déleste les serveurs centraux en les allégeant du travail « idiot » de distribution de fichiers.

La première utilisation des Clouds a été ce CDN, les pionniers du décentralisé étant par exemple Akamaï. Mais de nos jours, les ténors comme Amazon ou Google ont rationalisé des infrastructures beaucoup plus vastes et complexes que ce qui avait été conçu jusque là. Ils ont mis en place des systèmes spécifiques, allant parfois même jusqu’à faire développer leur propre hardware.

Une fois la puissance rationalisée et déployable à loisir, il est devenu simple pour ces ténors de « revendre » leur capacité d’accueil. Nous sommes alors passé du simple CDN à de la capacité d’accueil réelle avec, notamment, l’ajout de systèmes de base de donnée.

E.T.C (*) : Extend to Cloud, le cloud pour Magento

Chez NBS System, on a dû très tôt trouver des solutions à ce problème. Les grands comptes étant de plus en plus nombreux à basculer sous Magento et il était indispensable de proposer une solution rationnelle pour les accueillir.

Les éléments étant réunis, le projet E.T.C : Extend To Cloud était lancé. Une discussion avec Yoav Kutner, pas mal de test et de R&D et voici E.T.C.

Le concept est, dans le principe, simple. Au moment où un site monte en volume de trafic, on instancie des parcelles du cloud pour accueillir une partie du trafic qui « déborde » de la capacité d’accueil physique, réelle. Si l’infrastructure physique permet d’accueillir 100 000 Visiteurs uniques par jour, l’E.T.C permet de multiplier par 4 à 5 cette capacité d’accueil.

Une fois les tests menés et les systèmes de déploiement / rétractation au point, il devient possible d’automatiser également la mise en place d’une extension vers
le Cloud (ETC) quand cela est nécessaire.

Conclusion

Évidemment, présenté comme cela, E.T.C c’est assez simple.

En pratique il existe pas mal de contraintes et de tests à mener. Les outils pour être complètement « élastique » sont assez technique à réaliser. Pour être francs, la R&D est « un peu » coriace mais le résultat est à la hauteur du boulot fournit !

Une capacité unique d’accueil, sans multiplier les serveurs à l’infini, mais qui peut, de manière élastique, s’auto dimensionner pour répondre à des très fortes charges temporaires. Bien évidemment il y a un coût de setup assez minime et ensuite subsiste uniquement un coût d’usage qui est très très nettement plus intéressant que le fait de multiplier les serveurs

L’offre est disponible dès ce mois de décembre  2009.

(*) E.T.C (Extend To Cloud) est une marque et une technologie NBS System.

Cet article est le premier d’une série de 3 sur la configuration d’un infrastructure Magento complète, comprenant pour l’exemple un serveur qui sera Firewall/Reverse proxy/Load Balancer, deux autres qui seront des Serveur Web frontaux et un quatrième qui sera en charge de la base de données.

Plan des posts

1/3 : Configuration du firewall, du load balancer et du Rproxy
2/3 : Configuration des serveurs Web (APC / Apache / PHP)
3/3 : Configuration de la base de données (Mysql)

Le setup de l’infrastructure Magento

Internet, routeurs et hop, on tombe sur quoi ?

Le Firewall, reverse proxy, load balancer.

Le premier élément réellement intelligent et puissant sur lequel on va pouvoir travailler, le premier serveur quoi. Parfois l’élément Firewall est séparé et repose sur une appliance en amont mais dans le principe, si vous faites dans le full opensource, vous aimez netfilter et donc le firewall de Linux.

C’est par ailleurs un excellent Firewall, je vais donc l’intégrer à ce petit tuto et même démarrer par là !

Pour cet exemple et le paramétrage des fichiers de configuration, le firewall/RP/LB est en 192.168.1.1, les serveurs Web sont en 192.168.1.2 et .3 et la DB est en 192.168.1.4 et le magasin « virtuel » s’appel www.demostore.fr.

Enfin, cote ip publique, j’ai utilisé 33.44.55.66 comme étant celle de demostore.fr et 88.77.111.222 comme étant celle des admins. Vous trouverez ces paramètres dans les fichiers de configuration du firewall, du reverse proxy et du load balancer, il faudra les modifier pour vos besoins.

Points non couverts dans ces 3 articles

Je vais me la jouer un peu à la Ruquier, donc ce soir, on ne recevra pas, euh pardon, dans cette série de 3 articles, on ne verra pas :

• Comment faire de la redondance mutli datacenter avec BGP et les synchros de sites & de DB
• Comment séparer les flux de bases de données en écriture & lecture sur deux DB
• Comment faire du Master/Master Master/Slave ou du Cluster en Mysql
• Comment isoler le backoffice en terme de performances sur les serveurs frontaux
• Comment isoler le backoffice en terme d’accès aux bases de données

On ne verra pas tout cela car :
D’une part parce que cela serait très long et très complexe à expliquer et que les compétences nécessaires pour faire le tour du sujet sont très vastes. D’autre part parce que ca va déjà faire un bon volume à rédiger et donc que ca va prendre du temps. Et enfin parce que ces points sont très critiques sur le terrain commercial et qu’ils sont actuellement des avantages en faveur de ma société vis à vis de ses concurrents.

Vu que la concurrence dans le milieu de l’infogérance Magento est assez active, ma société NBS System ne peux pas se permettre de révéler ses tous derniers tricks ou ses toutes dernières optimisations pour l’infogérance ou l’hébergemnt de Magento, mais ce qui sera décrit dans les 5 articles correspond à ce que nous utilisions fin décembre 2008, donc des configurations tout à fait décentes et efficaces.

En plus mes collègues bossent en ce moment même avec Zend pour faire un papier très complet sur les performances et l’optimisation avec ZAS (Zend Application Server), je ne vais donc pas dévoiler de secrets avant la publication officielle au Bargento 2.

Préambule sur GRSEC/PAX

Autre point, c’est peu décrit dans cet article mais plus dans un autre dont je donne le lien et aussi sur le net : GRSEC + PAX c’est l’assurance vie de vos serveurs. Ce n’est pas une option : c’est un pré-requis. Grsec/Pax impose de recompiler le kernel, tache un peu complexe quand on a pas l’habitude mais le couple vous protège à 99,999% contre tous les overflow, les off by one et autres cochonneries de ce genre. Que ce soit apache, mysql, php, squid, memcached, apc etc… tous ces applicatifs peuvent avoir un jour une faille de sécurité. Grsec c’est l’assurance que même si ca se produit (et ca se produira), vos serveurs ne seront pas compromis.

Le Firewall

Configuration simple

J’ai réalisé, il y a (très) longtemps de cela, un petit tutoriel pour prendre Iptables & Netfilter en main. Il est incomplet, très vieux, contient des erreurs ou des abbérations que je n’ai pas eu le temps de corriger dans les scripts mais les explications et schémas sont corrects. Vous remarquerez au passage ma maîtrise considérable dans la création de page Web, celle-ci à faillit avoir de nombreuses récompenses pour l’utilisation audacieuse des CSS, mais finalement le jury a préféré un autre site (curieusement).

Ceci étant, ce que l’on souhaite faire ici est assez simple :
- Interdire tout par défaut (comme tout firewall décent)
- Authoriser spécifiquement les connexions d’administration depuis nos IP
- Permettre d’accéder directement aux serveurs derrière également depuis nos IP

Attention, il existe de très nombreux tricks à mettre en place pour avoir le top du top, dans le /proc/sys/net/ipv4, afin d’ajouter des règles anti DOS, d’ajuster la stack IP pour la gestion des connexions demi ouvertes, gérer la réduction des timeouts, et puis aussi par des règles pour loger les attaques, ajouter des systèmes de sondes/IDS etc…

C’est un firewall assez basique que je vais exposer ici. Pour de très fortes charges, il faudra également vérifier les capacités de NAT de la machine qui repose sur un système de buckets, lui même calculé en fonction de la RAM de la machine. Il faudra également redonder la machine, etc… (Mais avant que vous en soyez là, vous pourrez largement vous payer les services de personnes qui voient très bien de quoi je parles)

Préparation du Kernel :

1. On télécharge les patchs de GRSEC ici, ici (et en option le patch pour iptables ici)
2. On télécharge le kernel qui va avec la version de grsec ici
3. On détar/dézip les archives et on applique les patchs (bzip2 -d kernel*; tar xvf grsec*;patch -p0 < gr*.patch)
4. On ajoute deux ou trois tools qui risque de manquer : install libncurses-dev ncurses-dev make gcc paxtest gradm2 chpax
5. On configure le kernel (make menuconfig), voici l’ultra minimum :
   - Pas de support des modules, tout en statique (ca évite l’insertion de backdoor)
   - networking/networking options/netfilter/ip:netfilter configuration/activer la majorité des options
   - Security options / Grsec: activez tout sauf dans kernel auditing juste les relocations et forks, dans Pax mettez tout.

C’est une config ultra minimaliste. Pour plus d’info de nombreux sites parle de la compilation du noyau, le howto iptables est un peu plus précis aussi mais c’est trop long à expliquer pour avoir une place ici. Après, de nombreuses petites ou grands optimisations peuvent être effectuées au niveau du noyau, les résultats, du coté performances, comme du coté sécurité s’en ressentiront. Disons que si vous avez correctement configuré votre kernel avec pax et grsec, normalement les autres options par défaut sont rarement débiles.

Pour le firewall à proprement parler, on va faire simple dans un premier temps :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

#!/bin/bash
# short, simple, incomplete, not really commented iptables script for Debianed firewalls/rproxy/load balancers by Philippe Humeau (c) 2009 NBS System, lord Rusty forgive me, amen
 
IPTABLES="/sbin/iptables" 
 
case "$1" in
start) 
 
date=`date +'%b %d %k:%M:%S'`
ADMIN_IP="88.77.111.222" # <-------------- Change me !
SERVERS_IP="192.168.1.0/24"
SERVERS_WEB1="192.168.1.2"
SERVERS_WEB2="192.168.1.3"
SERVERS_DB="192.168.1.4"
INET="eth0"
SERVERS="eth1"
 
echo "$date -- Starting Firewall --" >> /var/log/kern.log
 
echo -e "-> \033[40m\033[1;31mSetting Default Policies to DROP \033[0m <-"
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP 
 
echo -e "-> \033[40m\033[1;33mFlushing all rules & tables \033[0m <-"
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
$IPTABLES -t nat -Z
$IPTABLES -t nat -X
$IPTABLES -N LOG_DROP
$IPTABLES -A LOG_DROP -m limit --limit 6/h --limit-burst 1 -j LOG --log-tcp-options --log-prefix 'Dropped: '
$IPTABLES -A LOG_DROP -j DROP
$IPTABLES -N syn-flood
$IPTABLES -A syn-flood -m limit --limit 10/s --limit-burst 10 -j RETURN
$IPTABLES -A syn-flood -j DROP 
 
echo -e "-> \033[40m\033[1;34m Set kernel networking tweaks \033[0m <-"
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 16384 > /proc/sys/net/ipv4/ip_conntrack_max
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 2400 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 0 > /proc/sys/kernel/printk
echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
echo 0 > /proc/sys/net/ipv4/tcp_sack
echo 64 > /proc/sys/net/ipv4/ip_default_ttl
echo 2048 > /proc/sys/net/ipv4/ip_queue_maxlen
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/tcp_ecn
 
echo -e "-> \033[40m\033[1;33m INPUT RULING \033[0m <-"
$IPTABLES -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -i $INET -s $ADMIN_IP -j ACCEPT
$IPTABLES -A INPUT -i $SERVERS -p tcp --dport 11211 -j ACCEPT # memcached
$IPTABLES -A INPUT -i $SERVERS -s $SERVERS_IP -j ACCEPT        # accept très (trop) générique pour les requêtes des serveurs au rp/lb/fw
$IPTABLES -A INPUT -p ICMP -i SERVERS -s $SERVERS_IP -j ACCEPT
$IPTABLES -A INPUT -p ICMP -i lo -j ACCEPT
$IPTABLES -A INPUT -i $INET -s $SERVERS_IP -m limit --limit 3/m -j LOG_DROP # "Spoofed packet: "
$IPTABLES -A INPUT -f -m limit --limit 3/m --limit-burst 1 -j LOG_DROP # "Frag packet: "
$IPTABLES -A INPUT -i $INET -p icmp -m limit --limit 12/hour --limit-burst 1 -j LOG --log-prefix "ICMP: "
$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/m --limit-burst 2 -j LOG_DROP # "SSH loggin attempt"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth XMAS scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -m limit --limit 3/m --limit-burst 5 -j LOG_DROP --log-prefix "Stealth XMAS-PSH scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth XMAS-ALL scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth FIN scan"
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth SYN/RST scan"
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth SYN/FIN scan(?)"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth Null scan"
$IPTABLES -A INPUT -p tcp --dport 0 -m limit --limit 6/h --limit-burst 1 -j LOG_DROP # "Port 0 OS fingerprint"
$IPTABLES -A INPUT -p udp --dport 0 -m limit --limit 6/h --limit-burst 1 -j LOG_DROP # "UDP port 0 OS fingerprint"
$IPTABLES -A INPUT -p tcp --sport 0 -m limit --limit 6/h --limit-burst 5 -j LOG_DROP # "TCP source port 0"
$IPTABLES -A INPUT -p udp --sport 0 -m limit --limit 6/h --limit-burst 5 -j LOG_DRop # "UDP source port 0"
$IPTABLES -A INPUT -p tcp -m multiport --sports 20,21,22,23,80,110,143,443,993,995 -m limit --limit 6/h --limit-burst 1 -j LOG_DROP # "Napta/smurfing/Drd/Dos"
$IPTABLES -A INPUT -i $INET -p tcp ! --syn -m state --state NEW -j DROP # "drop TCP connexion wich doesn't start by a syn"
$IPTABLES -A INPUT -m state --state INVALID -j DROP
$IPTABLES -A INPUT -i $INET -p tcp --syn -j syn-flood 
 
echo -e "-> \033[40m\033[1;32m FORWARD RULING \033[0m <-"
$IPTABLES -A FORWARD -m state --state INVALID -j DROP
$IPTABLES -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INET -o $SERVERS --dport 80 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $INET -o $SERVERS --dport 443 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 20 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 21 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 22 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 25 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 80 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 443 -p tcp -m state --state NEW -j ACCEPT 
 
echo -e "-> \033[40m\033[1;32m OUTPUT RULING \033[0m <-"
$IPTABLES -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -p ICMP -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 20 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 21 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 22 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 25 -j ACCEPT
$IPTABLES -A OUTPUT -p UDP --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 80 -j ACCEPT
$IPTABLES -A OUTPUT -p UDP --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 443 -j ACCEPT
 
echo -e "-> \033[40m\033[1;33m Masquerading \033[0m <-"
$IPTABLES -t nat -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
$IPTABLES -t nat -A POSTROUTING -i -o $INET -j MASQUERADE
 
echo -e "-> \033[40m\033[1;32m Firewall Setup complete, activating Forward \033[0m <-"
echo 1 > /proc/sys/net/ipv4/ip_forward 
 
echo -e "------------------------> \033[40m\033[1;32mEOF : End of Firewall \033[0m<-----------------------"
;; 
 
stop)
echo -e "\033[40m\033[1;31m----------------------> Shutting down Firewall ! <----------------------\033[0m"
echo " "
IPTABLES="/sbin/iptables"
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
$IPTABLES -t nat -Z
$IPTABLES -t nat -X
echo 0 > /proc/sys/net/ipv4/ip_forward
echo "-> DONE ! <-"
;;
 
*)
echo "Usage: /etc/init.d/firewall {start|stop}"
exit 1
;;
 
esac
exit 0

Quelques points :
- N’oubliez pas de durcir tous vos noyaux de serveurs, tout spécialement celui-ci, avec le patch GRSEC pour le kernel Linux. (ca doit aussi être décrit dans le howto de mémoire).

- Si on veut être plus méchant, au lieu de DROP on peut utiliser TARPIT si on a compilé iptables avec, ca fait un bel effet sur la machine attaquante !

- Si le scipt ne charge pas c’est que j’ai fais un faute de frappe quelque part, corrigez là Si il ne charge pas parcequ’il manque des target, ajoutez les dans le noyau au moment de sa compilation.

Le Reverse Proxy

Introduction

Le Firewall est une fonction en soit est très peu consommatrice car, sur un noyau linux, c’est embarqué. Netfilter et son application de pilotage iptables sont des outils très puissants et très économes.

Dans le cas qui nous préoccupe, c’est d’autant plus vrai qu’on va filtrer très peu de chose, ce n’est pas non plus le firewall du pentagone, on va juste protéger les accès d’administration. Sur notre beau serveur, on a dépensé 0,000001% de la capacité CPU, que faire du reste ?

Hummmmm du folding@home, du calcul de Pi, un serveur Quake 3, du Seti project : non !

On va faire un reverse proxy et un load balancer qui eux peuvent commencer à occuper un peu la machine sur ses 99,999999 % de temps CPU restant.

Le reverse proxy, c’est une histoire un peu plus complexe. Si on part sur une solution simple, Squid est très capable. Pour de la dentelle, qui nécessite aussi une optimisation du code pour en tirer le plein partit, Varnish est une solution plus costaud mais réellement plus longue à mettre en place. On va donc ici s’atteler à concevoir un Squid correcte.

Rôle

Le rôle du reverse proxy c’est ca :

Réduire les accès aux serveurs Web en les allégeants de tout ce qui n’a pas de valeur ajouté, tout ce qui n’est pas généré. J’ai pris volontairement une page très lourde pour la démonstration.

En l’occurence on va cacher :

• Le HTML
• Les CSS
• Les images
• Les fichiers Javascript

et forcément, le serveur Web, ca lui fait du bien. En résumé, il se concentre sur les requêtes Ajax et le PHP, il laisse les transferts « de base » au Rproxy. Evidemment, un tour de magie de ce type, ca consomme un maximum en RAM car il faut tout stocker en RAM pour aller vite. Si on doit charger chaque éléments depuis le disque dur, c’est plutôt lent. Un bon reverse proxy a donc beaucoup de RAM et un processeur correct, sans plus puisque la charge processeur est faible.

Au final, même si l’exemple ici, un peu exagéré, montre un gain de 97%, on gagne quand même en général au minimum 75% de trafic en moins vers le ou les serveurs Web. Donc qu’on ait un serveur Web ou plusieurs, le reverse proxy est in-dis-pen-sable.

Une autre optimisation intelligente sur ce point est à faire au niveau du code. Un fichier JS, un fichier CSS et pas des millions, ca change des choses. Du coup, concaténer tout cela intelligemment, c’est un plus non négligeable. Un gars s’est pris la tête à faire le boulot pour vous et encore mieux, il en a fait un plugin Magento, que demande le peuple ? Au fait ca s’appel Fooman speedster module et, depuis l’invention de la fénéantise, c’est un des outils les plus indispensable pour optimiser sans se fatiguer.

Installation de Squid

Vous êtes des gens biens, vous avez une Debian.

Vous pouvez aussi être des gens bien et ne pas avoir de Debian mais dans ce cas vous savez installer une tarball ou un package. Il y a même des gens bien qui travaillent avec OpenBSD par exemple, ils ont toute ma considération mais je ne ferai pas de howto pour (Il n’y a plus de gens bien sous HPUX rassurez moi ?)

Le coté « à la main », je sais faire aussi mais, personnellement, j’adore APT et DPKG

Attention, on se concentre, installer Squid ce n’est pas simple sous debian :

~> su (on passe root car on est jamais loggé en root par défaut)
~> apt-get install squid

Ok on respire, on a fait le plus dur. Un petit café pour se récompenser s’impose, bravo, vous avez bien bossé ! (merci aux gars de Gnu aussi). Ca c’est fait, Squid est installé, on souffle, on respire, c’était dur mais la vie est dure parfois.

Configuration de squid en reverse proxy Magento

Phase 2, on essaye de faire croire aux patrons qu’on est payé à faire quelque chose de balaise et incompréhensible, qui mérite probablement une augmentation énorme mais qu’on va se contenter de 10% et une voiture de fonction : on édite le fichier de configuration.

Bon Squid c’est un proxy et un reverse proxy. En gros ca permet dans un cas comme dans l’autre de gérer un cache pour que les fichiers régulièrement demandés soient dans un cache rapide, mémoire de préférence, plutot que redemandés voir ré interprétés par le serveurs Web. Ca allège énormément les serveurs dans le cas du reverse proxy. Le proxy cache les réponses des serveurs Web aux browsers http pour les acheminer au client sans les redemander. Le reverse proxy lui fait l’inverse (d’où le reverse), il stocke les réponses les plus souvent envoyées par le serveurs aux clients afin de servir ceux-ci sans demander quoique ce soit aux serveurs Web.

Bref Squid c’est complexe, énorme, un fichier de conf de base ca fait dans les 7000 lignes avec les commentaires, je vous livre donc ici une version expurgée des commentaires, juste préparer pour du reverse proxy et dont toutes les fonctions ne sont pas activées, juste les principales. Encore une précision, quand vous utilisez un reverse proxy, n’oubliez pas que votre serveur Web ne verra plus toutes les requêtes… Eh oui, c’est bien le but d’ailleurs. Donc ce qui est intercepté doit être minutieusement loggé pour pouvoir avoir des stats et compléter celles des serveurs Web sous Apache.

Allez, voici la configuration :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

# Squid sooooo basic configuration for Magento, by Philippe Humeau & Adrien Urban (c) 2009 NBS System
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80		# http
acl Safe_ports port 443		# https
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
icp_access deny all
htcp_access deny all
 
http_port 192.168.1.1:80 transparent name=proxy_int_IP
http_port 33.44.55.66:80 transparent name=ip_demostore
hierarchy_stoplist cgi-bin ?
 
cache_mem 6144 MB
maximum_object_size_in_memory 8 MB
memory_replacement_policy heap lfuda
cache_dir null /tmp
 
 
access_log /var/log/squid3/access.log squid
access_log /var/log/squid3/access-apache.log combined
refresh_pattern (cgi-bin|\?)	0	0%	0
refresh_pattern .		0	20%	4320
icp_port 3130
 
acl localhost src 127.0.0.1/8
acl localnet src 192.168.1.0/24
 
acl debianUpdate dstdomain ftp.fr.debian.org              # pour les updates Debian
acl debianUpdate dstdomain security.debian.org          # pour les updates Debian
acl dstOutAllowed dstdomain ws.mperf.com                # pour le mailing, remplacer mailperf par votre fournisseur
acl dstOutAllowed dstdomain chart.apis.google.com      # pour les beaux graphs à la google style
acl dstOutAllowed dstdomain www.magentocommerce.com     # devinez
acl dstOutAllowed dstdomain connect.magentocommerce.com # devinez v2.0
acl dstOutAllowed dstdomain pear.php.net                           # devinez v3.0
acl dstOutAllowed dstdomain schemas.xmlsoap.org                # pour les wsdl, soaperie et autres webservices
 
http_access allow localnet debianUpdate
http_access allow localnet dstOutAllowed
 
acl IpInternal myportname proxy_int_IP
acl IpExternal myportname ip_demostore
acl dstdemostore dstdomain www.demostore.fr
acl dstdemostore dstdomain demostore.fr
never_direct allow dstdemostore
 
# demostore
cache_peer 192.168.1.2 parent 80 0 no-query round-robin sourcehash
cache_peer 192.168.1.3 parent 80 0 no-query round-robin sourcehash
cache_peer_access 192.168.1.2 allow dstdemostore
cache_peer_access 192.168.1.3 allow dstdemostore
 
cache_peer_access 192.168.1.2 deny all
cache_peer_access 192.168.1.3 deny all
 
http_access allow dstdemostore
 
http_access deny all
 
access_log /var/log/squid3/demostore-squid.log squid demostore
access_log /var/log/squid3/demostore-apache.log combined demostore

Dans cet exemple, votre serveur dispose de 8 Go de Ram et on en prend 6 pour le cache de squid. C’est évidemment à ajuster en fonction de votre configuration. (cache_mem 6144 MB) On a aussi une taille maximal de fichier à 8 Mo pour cacher les gros objets et on interdit le cache sur disque pour ne pas gréver les performances. On a paramétré le service Squid pour gérer www.demostore.fr et demostore.fr et donné l’accès aux serveurs vers d’autres hosts comme Magento connect ou les updates de Debian.

Le load balancer

Bonne nouvelle : c’est déjà fait !

Eh oui en donnant deux peers vous avez dit à Squid qu’il avait deux serveurs Web dont il devait s’occuper. Vous pourriez vouloir donner un poids différent (ici dans l’exemple c’est du 50/50) si vous avez des serveurs de puissance différentes. Il faudra alors ajouter Weight comme directive dans la déclaration des peers.

Le piège serait de faire du load balancing IP. Netfilter sait le faire, c’est même assez simple à mettre en oeuvre et pour tout vous dire c’est ce qu’on faisait à NBS System avant. Mais cela posait des problèmes quand le client arrivait d’une IP qui changeait en cour de session (gros firewall corporate qui nat par une autre connexion ou même simplement une adsl en ip variable). Du coup il vaut mieux passer par cette solution qui est plus propre.

Memcached

Introduction

Nous y voila, la fin de l’aventure Firewall / Load Balancer / Reverse Proxy est proche…

Si je finis par ce point c’est aussi parce que c’est le plus facile quelque part.

On peut mettre memcached un peu partout dans l’infrastructure, sur le proxy, sur les serveurs Web ou même sur les serveurs de base de données. L’idée c’est de garder les sessions des surfers non pas en fichiers mais en mémoire. D’un point de vue performance, c’est très préférable et c’est simple à réaliser alors pourquoi s’en passer…

Installation

On peut le mettre dans plusieurs endroit ce fameux memcached mais je préconise un serveur qui est unique et accédé / accessible par tous comme la base de données (si on a qu’un serveur de DB) ou le reverse proxy mais, si possible, pas sur les serveurs Web. En effet si l’un tombe, autant que l’autre puisse bosser et reprendre ses sessions. Evidemment, il vaut mieux que le dit serveur soit redondant ou bien costaud pour ne pas tomber sinon c’est toutes les sessions qu’on perd mais vu que le site tombera avec, ca sera un moindre problème

Oui, je sais, toujours un peu douleureuse cette phase sous Debian :
~> su (on passe root car on est plus loggé en root, normal)
~> apt-get install memcached php5-memcached

Allez, ca va aller, c’est finit… On respire lentement, le rythme cardiaque redescend !

Configuration

Dans le fichier local.xml de Magento, vous devriez pouvoir ajouter :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<global>
  <cache>
    <backend>memcached</backend>
    <memcached>
      <compression/>
      <cache_dir/>
      <hashed_directory_level/>
      <hashed_directory_umask/>
          <file_name_prefix/>
          <servers>
             <default>
              <host>192.168.1.1</host>
              <port>11211</port>
             <persistent>1</persistent>
           </default>
          </servers>
      </memcached>
  </cache>
<session_save><![CDATA[memcache]]></session_save>
<session_save_path><![CDATA[tcp://192.168.1.1:11211?persistent=1]]></session_save_path>
</global>

On peut aussi mettre memcached en dehors de Magento et de sa configuration, tout simplement en installant le démon avec une configuration dans le /etc/memcached.conf :

1
2
3
4
5
6
7

# memcached ultra simplistic config file by philippe Humeau (c) 2009 NBS System
-d
logfile /var/log/memcached.log
-m 1024
-p 11211 
-u nobody
-l 192.168.1.1

Conclusion

1. Vous méritez un café après tout ce travail
2. Je mérite un café après ce travail de rédaction
3. Il est incompréhensible que les producteurs de café soient pauvres
4. La personne qui monte un site Magento entièrement dédié au café, il va se faire du blé

Oui… Je sais… J’ai toujours un petit soucis sur les conclusions mais bon, vous commencez à être habitués depuis le temps et puis je me soigne.

Prochain exercice de style, l’article 2/3 : Configuration d’un serveur Web pour Magento !

PS : N’oubliez pas de vous inscrire pour Bargento 2, il reste encore quelques places et après on est complet, ce qui implique que même en arrivant à l’improviste sur place, on ne pourra pas vous faire rentrer pour rester dans les capacités d’accueil de la salle.

De plus, le papier sur Zend Application Server et les performances de Magento devrait apporter un jour nouveau et pas mal de complément sur ce mini tuto / howto.

Par manque de temps, je n’ai pas eu le temps de tout tester sur un serveur donc si il y a des boulettes dans les fichiers de configuration, n’hésitez pas à me les signaler, je modifierai l’article.

C’est beau, c’est clair et… très pertinent !

Ils nous parlent aussi du fooman speedster module qui vient de passer dans le magento connect depuis le 22/03 !

En un mot comme en 100, jetez y un oeil ca vaut le coup. Depuis le temps que je grogne sur le fait que les sites nous arrivent en hébergement sont, neuf fois sur dix, pas optimisés pour un rond… Enfin un homme bon et généreux vous propose de grouper et compresser vos CSS et vos JS !

Globalement, ce joli petit module vous permet de regrouper (presque) tous vos Javascript en un ficher, idem pour les CSS. Il y a quelques exceptions, le classique print.css par exemple, mais sinon, sincèrement, s’en passer c’est se tirer dans le pied !

Alors, où en est-on sur le front des performances ?

Eh bien si vous avez mis en place les optimisations qui sont recommandées, celles que l’ont vous a expliqué chez Fragento ou ici, celles que l’on va vous exposer dans les prochains posts, bref si vous faites les choses correctement, vous pouvez atteindre de 200 à 800 sessions « Magento connectées » par core (coeur) de vos processeurs récents.

Mais avant de parler des optimisations en elles mêmes, il faut avoir des moyens de comparer, des unités et des repères communs. Je vous propose d’adopter des « S.M.C » comme unité.

S.M.C ?

En premier lieu « Sessions Magento Connectées », qu’est-ce que cela peut bien représenter… ?

Déjà, on va réduire le nom à SMC pour éviter de trimbaler 5 lignes. On peut prendre de nombreux points de repères différents pour estimer la charge : les sessions apache, les Visiteurs Uniques (V.U) journaliers, horaires, le nombre de page vues, etc… Alors pourquoi choisir les SMC ?

Les SMC cela reste un indicateur pertinent car c’est Magento qui mesure cette valeur. Elle peut donc être utilisées dans d’autres contexte, pour faire d’autres calculs mais surtout elle est mesurée partout de la même façon, ce qui est important pour avoir des repères. Comme c’est Magento qui la mesure, on travail tous sur la même valeur.

Comment les récupérer ? Avec une requête SQL en base de données tout simplement :
select count(*) from log_visitor where ADDTIME(utc_timestamp(), -1500) < last_visit_at;

Cela nous donne les sessions ayant eu une activité lors des 15 dernières minutes. C’est très proche de ce que l’on a dans le backoffice. Une dataquery et un script bash plus tard,

On en fait un beau graphique pour les clients dans Cacti ou avec RRD, MRTG etc… :

Là, par exemple, on voit un mailing. Monté en charge progressive du nombre de SMC pour atteindre les 1200 vers 18H00. Ca se corrèle bien avec le graphique d’utilisation des cores :

On 4 cores utilisés pour 1200, donc 300 utilisateurs par core, en l’occurence ce sont des AMD Shanghai 2374 à 2,3 Ghz. Comme ce sont des quad cores, on utilise un processeur complet. Évidemment on ne peut pas se permettre d’avoir tous les cores à 100% donc les autres processus Linux tournent sur un autre core dédié d’un autre processeur. Coté base de données, ca glandouille gentillement :

Il faut lire 0,2 core (200 milli). Ceci étant ce site spécifique sollicite peu la base de données donc ce n'est pas représentatif non plus.

Tester les performances, tests de charge & Benchmark !

De nombreux outils existent, qui mesurent différentes choses. En test de charge purs, on a par exemple Load runner, Apache bench, Opensta etc… Coupler tout cela à des analyseurs de code ou de requêtes SQL (comme la console Mysql enterprise par exemple) permet d’optimiser le code mais ce n’est pas le sujet de ce post et Gilles nous fera peut être un petit article là dessus.

Non, ce qui nous intéresse ici, c’est d’évaluer le nombre de SMC que l’on peut servir dans de bonnes conditions avec la plateforme que l’on aura préparé. Pour cela, load runner et Opensta sont de bons outils. Apache bench n’est pas très adapté sincèrement car son test est toujours le même, donc avec la chaine de cache, à la fin de ces 2000 itérations, il vous sort joyeusement 250 000 connectés

Opensta permet de définir des scénarii de tests et d’en jouer plusieurs, de front, à suivre, plusieurs fois les mêmes etc… Le soft tourne sous Windows, il est gratuit et opensource. On peut le trouver ici et même s’il n’est plus entretenu, il fonctionne bien et fait le boulot demandé.

Le but ici n’est pas de faire un manuel ou un howto d’opensta mais globalement d’expliquer ce qui représente de bonnes circonstance de tests, tout au moins réaliste. Ce que je fais, en général, c’est que je demande à mes clients, c’est de réaliser entre vingt et trente scénarii classique de surf. On enregistre un très simple de la personne qui vient sur la home et se déconnecte, un autre ou il fait une recherche un autre ou il clique de produit en produit, etc… Le plus le mieux mais également, le plus logique le mieux !

Le scénario de connexion à la home puis déconnexion, on va le jouer 25% du temps, puis celui du parcours de produit 1, le 2 et aussi les recherches. On mixe le tout savamment et on demande à plusieurs scénarii de se jouer sur le site. Trois qui surf, des connexions déconnexions sur la home, deux recherches en même temps etc… A la fin, on regarde les performances affichées par l’interface d’Opensta et celles collectées dans Cacti. On corrèle les graphs, on analyse et on arrive à estimer la charge que peux tenir un système ! En laissant tourner les scénarii un moment, le graph sera réaliste et on saura dire combien de S.M.C peut faire tenir un core standard.

La suite est un jeu d’enfant, on prend le nombre de V.U prévu en pic, on déduit le nombre de S.M.C que l’on doit pouvoir encaisser et on divise par la performance unitaire d’un Core. On sait alors combien de core on doit mettre en place et donc combien de processeurs !

Bon si une bonne âme veut bien écrire un tuto/howto sur Opensta, je passe mon tour pour le moment et je vous laisse juste en compagnie de deux shoots d’écran, le modeler et le commander :

On définit son scénario dans le modeler ci-dessous, on planifie dans le commander ci-dessus, et on a un autre module qui collecte et affiche les statistiques.

Et voila !

Je voulais vous faire un petit tutorial sur comment optimiser un peu les pages en elles-mêmes, et finalement on va commencer par quelque chose de plus basique la compression des pages.

La première étape que je vous propose, c’est de télécharger pour ceux qui ne le connaissent pas encore un plugin pour firefox nommé Yslow qui nous donne de nombreuses informations sur l’optimisation de votre site. Ce plugin développé par Yahoo fait parti d’un ensemble de bonnes pratiques pour optimiser le temps de chargement de vos pages. Vous pouvez en retrouver la liste (en anglais) ici : http://developer.yahoo.com/performance/rules.html#cdn

Et en complément quelques idées supplémentaires sur leur blog de développement:
http://developer.yahoo.net/blog/archives/2008/03/yahoos_latest_p.html

Le premier onglet de ce plugin « Performance » nous donne des indications sur le respect de votre site de ces bonnes pratiques. Chaque élément est noté entre A et F et nous donne une idée des points que l’on a pu oublier, comme par exemple activer la compression gzip sur le serveur (bien que la note totale -souvent F- ne présente pas beaucoup d’intérêt car certaines règles sont difficiles à mettre en pratique).

On observe d’ailleurs que Magento respecte naturellement nombres de ces règles (une bien connue maintenant étant la minification des js).

Ce qui nous amène au deuxième onglet, l’onglet « Stats », celui-ci permet d’obtenir le poids total de votre page, ainsi que la répartition du poids entre les différents éléments (images, css, flash, html) ainsi que le poids de votre page une fois que les éléments ont été chargé une première fois et sont dans le cache du navigateur.

On voit ainsi dans cet exemple la différence de poids que l’on peut avoir entre une page d’accueil avec ou sans la compression gzip. Je pense que je n’ai pas besoin de vous expliquer l’intérêt d’économiser 200Ko de trafic pour chaque internaute qui chargera votre page d’accueil.

Enfin l’onglet « Components » nous permet d’avoir le détail pour chaque élément son poids (avant et après compression gzip), comme l’onglet Net (Réseau en français) du plugin Firebug, on peut voir en rouge les éléments qui n’ont pas été chargés ainsi que le temps de chargement de chaque élément. Cet onglet est intéressant puisqu’on peut classer les éléments par poids. On peut ainsi s’apercevoir qu’on a des images qui mériteraient une compression jpg plus forte, ou qu’un flash mériterait d’être optimisé (voir déplacé ou remplacé par quelque chose de plus léger si par exemple il est sur une la page d’accueil d’un site à fort trafic).

J’arrive à mon deuxième point, la compression gzip. En complément du plugin Yslow ce lien http://www.whatsmyip.org/mod_gzip_test/ permet de vérifier immédiatement que la compression est bien activée pour une url donnée.

Pour activer la compression gzip cela suppose que le module apache adéquat soit chargé (mod_gzip qui se nomme maintenant mod_deflate), je vous laisse vous tourner vers votre hébergeur ou google pour vérifier que ce module est chargé.

Ensuite quand le module est chargé, il faut également que les règles apache correspondantes aient été chargées, chose qui n’aura pas toujours été faite quand on vous livre un serveur. On a alors toutes les règles nécessaires dans le fichier .htaccess de notre bon vieux magento qu’il suffit de décommenter :

############################################
## enable resulting html compression

php_flag zlib.output_compression on

############################################
## enable apache served files compression
## http://developer.yahoo.com/performance/rules.html#gzip

# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems…
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don’t compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

# Make sure proxies don’t deliver the wrong content
Header append Vary User-Agent env=!dont-vary

(On peut évidemment appliquer directement ces règles dans le httpd.conf d’apache quand on sait ce que l’on fait).

Attention, si l’on transfert du Zip, le « php_flag zlib.output_compression on » va poser problème me remonte un lecteur !

Il est très complexe de dimensionner les serveurs nécessaires et ajuster les paramètres systèmes afin d’être sûr d’obtenir une navigation agréable pour un grand nombre d’utilisateurs. L’empirisme commence à bien fonctionner avec le recul de plusieurs sites hébergés mais je pense qu’on peut faire mieux et commencer à structurer des calculs plus scientifiques.

Je vous ai parlé des différents processeurs du marché et des infrastructures blades. Aujourd’hui quand un client me demande un hébergement, je dois partir de ce qui existe pour m’assurer des performances que je peux lui offrir : son site. Il est optimisé ou pas, on le voit vite, si les caches bloc/eav ont bien été activés dans le code, si les requêtes en bases sont bien conçues, si les fichiers CSS/AJX sont regroupés, etc… On sait que l’optimisation du site a été pensée (et réalisée) ou pas.

Partons du principe que le code a été optimisé et qu’on cherche maintenant juste à dimensionner. Plusieurs outils vont nous servir : les logs d’apache (ou du reverse proxy si il y a un load balancing), les logs des tests Opensta et les informations fournies par Google Analytics.

Analytics fournit une information qualifiée et permet de faire quelques projections. Le problème c’est que toutes les pages ne sont pas forcément taggées, elles ne sont pas forcément les mêmes entre l’ancien et le nouveau site et enfin seules les pages consultées sont prises en compte, les webservices, ajax, les transferts de fichiers plus ou moins volumineux et les autres facteurs ne sont pas pris en compte. Donc seul les pages php générées (ou rproxysées) seront prises en compte mais ca constitue déjà un premier indice sur la charge que porte le CPU. Dans analytics :

1. Dans le tableau de bord, prenez une période d’un jour de haute charge du site. (Un seul jour de sélectionné dans la période)
2. Cliquez sur visiteurs, puis visiteurs-tendances puis sur visites
3. Cliquez sur l’icone « Graphique horaire » à droite, juste au dessus du premier graphique
4. Prenez la tranche d’une heure qui contient le plus de visites et gardez le nombre au chaud
5. Allez ensuite dans nombre de pages vues, pour la même tranche horaire, prenez le chiffre
6. Allez enfin dans temps passé sur le site et prenez, toujours pour la même tranche horaire le temps moyen

Ensuite, avec la formule (((temps de visite moyen en seconde)*(nombre de visiteur horaire))/3600) / ((temps de visite moyen en seconde)/(nombre de pages par visiteurs), vous savez le nombre de pages que les serveurs doivent générer par secondes. Certains sites charges toujours les mêmes pages, d’autres ont des catalogues tellement profonds que les chaines de cache ne vont quasiment pas travailler.

Pour compléter l’analyse, faites des sessions Opensta, SQL Analyzer et regardez précisément le nombre de fichiers chargés, générés et le temps que le(s) serveur(s) met à répondre, par session. Jouez plusieurs profils différents, des vrais séances de surf pour que ce soit réaliste. (20 profils différents semblent raisonnablement précis) Une fois les profils fait, jouez en N en même temps, jusqu’à ce que le temps de réponse du site se mette à augmenter légèrement.

Vous avez alors trouvé, sur votre architecture de test, le nombre de personnes connectées simultanément.

Sur un site qui génère 20 000 visites par exemple, le nombre de sessions simultanées peut, en réalité, être assez faible avec des pics à 600 sessions simultanées « seulement ». Les sites étant tous différents dans leurs comportement, une seule méthode compte, simuler précisément, confronter à l’historique réel du site contenu dans analytics et extrapoler ces simulations du serveur de tests à la plateforme finale. Si vos simulations montrent un ralentissement après 150 sessions simultanées et que vous devez atteindre 600, il vous faudra 5 serveurs (4 + 1 autre fournissant les 20% de sureté).

On prépare un Guide de l’optimisation Magento qui sera articulé comme suit (à priori) :

1°) Introduction
2°) Infrastructure
3°) Système d’exploitation
4°) environnement LAMP
5°) Architecture/conception du code Magento
6°) Développement
7°) Optimisation (SQL&Code analyzer)
8°) Tests de charges / Benchmarking
9°) Les caches (memcached, rproxy, eav/zend)
10°) Nice things, hints & tricks

Comme mon équipe n’est pas spécialisée dans le développement, je pense que les chapitres 5/6 seront réalisés par des volontaires. De toute façon, tout cela se passera dans le Wiki.