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 ?

A la suite d’Imagine US et des technical tracks ainsi que de plusieurs lectures récentes, je vous propose quelques informations ou techniques que j’ai trouvé intéressantes.

J’allais également oublier, les slides de ma conférence à Imagine sont disponibles ici et la vidéo a été mise en ligne ici.

Zend asynchronous

Lors des tech tracks d’Imagine, j’ai aussi pu voir le passionnant papier de Kevin de Zend. Le principe est de faire des requêtes qui seront servies de manière Asynchrone, ni plus ni moins qu’un Job manager en fait. actuellement je recommandais l’usage de Gearman pour la plupart de gestions de Queue mais quand on a pas besoin d’un fonctionnalité aussi avancé, Zend Asynchronous peut être une ressource à la fois simple et efficace.

Le papier de Kevin est disponible ici.

Mysql, ca ne se scale pas…

On commence de plus en plus a avoir des sites énormes en hébergement. Que ce soit du Ecommerce ou des médias, un gros site va très clairement faire chauffer la base de données. Le soucis avec Mysql, largement reporté déjà mais visible entre autre dans ce thread sur le forum Mysql, c’est que InnoDB et MyISAM se scale très très mal.

Quand on a un serveur qui a plus de 4 processeurs (plus de 4 cores pour être précis), Mysql ne sait pas en tirer partie. Pire, c’est même parfois un handicape. Alors en attendant la version 5.4 qui nous promet une refonte massive de l’architecture multi thread de Mysql, on va devoir faire avec. En plus, depuis le rachat de Sun par Oracle et la politique mené par ce dernier, doublé du mouvement NoSQL, il n’est pas certain qu’on voit un jour cette version.

Pire, avec Oracle derrière, le principe de limitation de Mysql pourrait même faire les affaires du titan qui aurait un intérêt évident à ne pas corriger ce point afin de vendre de l’Oracle.

Alors il reste le moyen de chainer les serveurs à 4 cores… Master/Master/Master etc. Ou de séparer les Read et Write et on fait un Master / Slave. Mais rien de bien brillant pour des sites qui consomment de plus en plus de ressources.

La conception, encore et toujours

Shawan mon amour

On a eu un problème assez original il y a quelques semaines à NBS System. Un client a eu des soucis délirant de charge de sa base de données. Tout le monde s’est posé la question, Moooo gento ou problème plus technique ?

Une première réponse au problème a été une découverte (faite par la web agency), d’un soucis atypique… Quand on fait un mailing pour une vente privée ou des clients existants, il est possible de les authentifier automatiquement quand ils suivent le lien. C’est très confortable pour eux et plusieurs systèmes existent qui facilitent la vie des intégrateurs.

Oui mais…

Quand on fait ca sur une très large clientèle, selon la façon de le faire, cela peut avoir des incidences très sensibles. L’exemple ici c’est que la base de données se retrouvait à décoder des centaines de Shawan (Hash SHA1) à la secondes au moment du pic d’ouverture des mailings. Résultat, à chaque clic, la DB devait décoder le SHA1 et vérifier son authenticité et … ca la cassait en deux.

Ce travail doublé du travail normal de DB la mettait totalement à genoux. Une analyse des logs, des slow queries, des paramètres vitaux de serveurs et une collaboration entre l’infogérant (nous) et la web agency a permis de mettre un nom sur le problème et de le corriger. Vicieux celui-ci.

Conception de Home

Bien concevoir sa home reste une clef du succès d’un site. La charge imposé par la Home sur l’ensemble de la charge serveur dépasse souvent les 40%, il est donc important de concevoir de manière optimale  cette page qui est le premier accueil qu’un client reçoit.

Pleinnnnn de produits

Eh oui ma bonne dame, plus y’en a, mieux c’est.

Faux. Lisez ce qu’en penses mes amis les pros comme Capitaine Commerce, François Ziserman ou Catherine Barba, assommer les clients sous 200 produits en homepage, ca n’apporte rien sinon un client perdu. Et plus on charge de produits, plus on fait travailler la base de données et les CPU pour interpréter le PHP et plus… ca rame.

Donc on a des clients perdus sur un site qui rame. Êtes vous bien persuadé que c’est  ce que vous voulez ???
(Press Y to continue if you are sure)

Dynamique, non mieux, random !

Bien tiens… J’ai une ligne de conduite précise, je sais ce que je vend et à qui. Aucun doute à ce sujet, j’ai profiler ma clientèle alors pour optimiser mes ventes, je charge mes produits en random…

Alors je veux bien que dans certains cas cela puisse avoir, à l’occasion, du sens mais clairement pas en home et pas tout le temps. Amazon, notre maitre à tous, ils envoient pas des produits en random à leurs clients. Ce qui a boosté leurs ventes et surtout le panier moyen de chaque acheteurs, c’est tout l’inverse, c’est l’envoie de produits ciblés.

Alors charger dynamiquement oui, dans certain cas pour s’adapter au client mais en random… ?

Car oui, le random et le dynamique sont des ennemis des caches, ces fameux caches (reverse proxy, celui de votre system de e-commerce, memcached, le Full Page  Cache et dans une moindre mesure celui des processeurs et des opcode cache de PHP) sont assez allergiques au hasard.

Et le statique ?

Vous y avez pensé ? Une landing statique bien faite, qui a la calculer chaque nuit en Cron, ca peut faire la différence. Sincèrement, afficher moins et mieux pour fournir à tout le monde une expérience utilisateur plus fluide, efficace et rapide, c’est une stratégie payante.

Plus votre site est véloce, plus et mieux il vend, c’est plus que démontré.

Inline URI

Alors celui-ci de tricks, il est soooo sexy.

Il faudrait tester en live la chose et étudier si c’est rentable mais le principe est marrant. En gros, dans votre CSS, plutot que de mettre la référence à une image externe, vous allez mettre en place une  chaine de caractère encodée en base64 :

url(data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/XBs/fNwfjZ0frl3/zy7)

Ca donne un texte certe un peu chargé mais… Le Gzip est là pour nous aider. En gros le CSS va grossir, certes mais en contrepartie on peut le compresser en mod_gzip ou mod_deflate et finalement on n’a qu’une légère augmentation. Par contre, on économise autant de GET HTTP, ce qui n’est pas négligeable.

A vue de nez, je pense qu’il est valable de le faire pour les petites images, icones ou petits thumbnails. Il est possible aussi de faire un Sprite bien sûr, mais cette  technique alternative peut aussi avoir ses cotés sympas. Je dois avouer que c’est tout neuf pour moi alors je n’ai pas penssé à tous les points qui pourraient profiter des ces Data URIs.

(Beaucoup) plus d’infos sur cette technique ici : http://css-tricks.com/data-uris/

Comme souvent, quand vous avez un site Web à faire tourner ou à lancer, vous aller envisager de faire des imports. Que ce soit un one-time ou une automatisation, vous aller vivre avec une limitation de rapidité. Celle-ci est dûe en partie à la structure de la base en EAV et au fonctionnement du Framework.

Cette limite vous borne à un rythme de un a deux secondes par produits à 10/20 produits par secondes selon la méthode utilisée, la machine et la complexité de l’import.

Dès que l’on touche à une grande masse, gagner un peu va jouer beaucoup au final.

Vitaminer un peu vos bases

Désactiver les binlogs

Ce tips est utilisable aussi bien pendant vos imports que sur votre production. Seul petit soucis, sur la production, désactiver les binlogs va vous empécher de faire du master/master ou du master/slave (peut être du cluster je ne sais pas) et ca peut ne pas coller avec vos besoins.

Dans votre fichier my.cnf, pour désactiver les binlogs, vous pouvez passer la ligne sync_binlog=1 à sync_binlog=0.

C’est typiquement utile/faisable pour un mono serveur dédié ou virtualisé avec base de donnée et frontal web sur la même instance/machine.

Innodb_flush_log_at_trx_commit

Deuxième limite, si vous passer la paramètre innodb_flush_log_at_trx_commit à 2, vous aller limiter votre niveau de protection en cas de crash et encore, nous parlons ici de la dernière seconde de transaction. Vos machines sont censées être au chaud dans un datacenter, redondante et un crash arrive très très rarement. Une seconde de transaction, chez vente privée à 8h00 du matin, ca peut faire très mal, mais sur un site un peu plus raisonnable à minuit, ca ne représente en général rien. Le risque est donc très limité, d’autant que de nombreux hoster mette maintenant ce paramètre par défaut.

La doc de Mysql nous dit :
If the value of innodb_flush_log_at_trx_commit is 0, the log buffer is written out to the log file once per second and the flush to disk operation is performed on the log file, but nothing is done at a transaction commit. When the value is 1, the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file.

When the value is 2, the log buffer is written out to the file at each commit, but the flush to disk operation is not performed on it. However, the flushing on the log file takes place once per second also when the value is 2. Note that the once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues.

With a value of 2, then only an operating system crash or a power outage can erase the last second of transactions. However, InnoDB’s crash recovery is not affected and thus crash recovery does work regardless of the value.

Il faut savoir que les disques durs et les controlleurs peuvent aussi prendre sur eux de retourner un joyeux « ok c’est fait » alors qu’en fait, la donnée est en cache mémoire en attendant un flush… Mais dans ce cas, le mode 1 n’est pas plus sécurisant, donc autant rester sur le 2.

Pour modifier votre valeur de commit :
passer innodb_flush_log_at_trx_commit = 1 à 2

Résultats attendus

Si vous mettez ces deux valeurs en place, vous devriez avoir un gain de performances pour vos imports mais aussi en exploitation, de 20 à 40% de performances. C’est un choix à bien réfléchir cependant mais un risque limité. Coté binlog, c’est faisable ou non, tout dépend de votre environnement.

]]> http://www.wikigento.com/optimisation-lampzendmagento/optimiser_imports_magento/feed/ 0 http://www.wikigento.com/optimisation-lampzendmagento/backend-de-cache-magento/ http://www.wikigento.com/optimisation-lampzendmagento/backend-de-cache-magento/#comments Tue, 21 Dec 2010 16:01:23 +0000 Philippe Humeau http://www.wikigento.com/?p=1873 Magento : un cache capricieux ?

Voici un petit article composé suite à des recherches menées conjointement par NBS System et la Magento Academy.

En effet, le directeur de production (Emile pour les intimes) a touver un comportement étrange lors du paramétrage des systèmes Magento > 1.4.0. Avec l’apparition du slow backend, on avait en effet des résultats beaucoup plus « slow ».

Fabrice nous a proposé d’élucider certains mystères en allant faire de l’inspection de code. Voici les premiers retours :

Magento 1.4 : Changement du système de cache

Depuis la version 1.4 de Magento un nouveau système gérant le cache à été mis en place appelé cache à 2 niveaux.

Le premier niveau appelé fast backend est un cache rapide et est le cache principal et le second niveau, le slow backend et est un cache de secours en cas d’indisponibilité ou de saturation du cache de premier niveau.

L’utilisation de ce Slow Backend est imposé dès qu’un cache de premier niveau dit « rapide » est configuré.

Autrement dis même si vous ne configurez rien en slow backend, le simple fait d’utiliser APC, Memcached, Xcache ou Eaccelerator activera le cache de second niveau avec pour type un file cache.

Configurer son cache correctement

Magento attends comme valeurs de configuration dans le fichier local.xml les nœuds suivants :

<backend /> pour le fast backend

<slow_backend /> pour le slow backend

Magento attends normalement les valeurs suivantes (attention à la case) pour le noeud <backend> :

• file
• sqlite
• memcached
• apc
• xcache
• eaccelerator
• database

Toutefois pour le noeud <slow_backend> Magento attends les valeurs suivantes sous peine de plantage (attention à la case) :

• File
• Sqlite
• Memcached
• Apc, Xcache
• Varien_Cache_Backend_Eaccelerator
• Varien_Cache_Backend_Database

Un bug semble présent dans l’Admin quand le système de cache à 2 niveaux est présent, en effet dans Système > Gestion du cache, tous les caches semblent désactivé même s’ils le sont bien, il semble que ce soit un bug qui peut être corrigé facilement (même si l’on vous déconseille de patcher le Core a moins d’en avoir un suivi très précis) :

Dans le fichier app/code/core/Mage/Core/Model/Cache.php

Méthode _initOptions()

La ligne

if ($options === false) {

  devrait être

if ($options === false || $options === null) {

Toutefois ce bug ne semble se manifester que si le cache APC est plein.

Ce cache APC d’ailleurs se remplit en continue et n’est pas « rafraichit » assez vite, ce qui fait qu’on tombe vite dans le slow backend qui, s’il n’est pas configuré, atterrit sur les disques dur (ou en RAMdisk si vous en avez paramétré). Il reste possible de le nettoyer en l’effaçant mais ce n’est pas optimal.

Des arbitrages déroutants

Magento vérifie si le cache a suffisamment de place libre avant de faire les mises en cache. Pour APC c’est la consommation de mémoire qui est vérifiée, sur le taux d’utilisation dépasse 80% le cache APC est ignoré. Déjà, 80% de 64 Mo ou de 1 Go ce n’est pas la même chose, pourquoi ne pas mettre un seuil en Mégas plutôt qu’en pourcentage ?

A l’écriture Magento écrit dans APC à l’unique condition que son taux d’utilisation soit inférieur à 80%, dans tous les cas il écrira dans le slow backend.

A la lecture seul le fast backend est utilisé, s’il n’existe pas ou n’est pas disponible Magento lira dans le slow_backend

Notez que le cache à 2 niveau possède une option auto_refresh_fast_cache il semble bizarre car il ne fait que remettre en cache les données chargées depuis le cache repoussant ainsi sa date d’expiration, cela ne se fait que si le taux d’utilisation du cache est < 80%.

Conclusion sur le cache Magento 1.4+

L’écriture du slow backend est donc systématique mais ne se fait que si le fast backend doit écrire lui aussi, donc si tu ouvre une page le slow et le fast backend sont générés. Si par la suite on supprime les fichiers du slow_backend mais pas du fast, les fichier du slow backend ne seront régénéré que si le fast backend l’est aussi. Tant que le fast backend a un cache valide les fichier du slow backend ne sont pas régénérés.

Il n’y a donc pas de bugs majeurs dans la configuration, elle est juste un peu subtile à comprendre et non documenté ce qui n’aide pas. Par contre, le principe de l’utilisation du Fast et son taux de renouvellement trop faible en font un système moins efficace puisque le Fast est presque tout le temps plein, des données les plus anciennes.

Merci à Emile pour la piste et Fabrice pour l’analyse.

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

Sortie de la 1.4 CE

Bon, finalement c’est fait, la 1.4 de Magento est sortie. Vous pouvez la trouver ici et un compte rendu complet des nouveautés ici sur Fragento.

Donc après plusieurs mois d’absence, on va enfin pouvoir tester la bête en terme de performances et de sécurité. Je suis en tout cas rassuré que Varien n’ait pas mis de coté la CE plus longtemps car cela devenait politiquement problématique.

Bargento en régions = Apérogento ?

Gabriel et moi travaillons étroitement avec SeL et Varien à l’animation de la communauté Magento en France mais nous n’avons pas le temps de tout suivre ou de tout faire. J’ai appris avec surprise et joie que de nombreux évènements s’organisaient en région, des apérogentos notamment et je trouve cela super.

Vu de Paris, on ne peut pas beaucoup aider à cela me disais-je mais finalement j’ai revu mon jugement. Déjà, apéro ou autres horaires, on peut éventuellement passer faire un bonjour, ca nous fera plaisir, même si ca n’aide en rien les organisateurs

Par contre, on peut fournir un peu de logistique aux organisateurs ! De la visibilité en annonçant ca sur Wikigento, Bargento (et probablement Fragento même si je n’en ai pas encore parlé à Gabriel) voir même en faisant poster par Varien un billet avec un espèce d’agenda sur le blog FR.

Ensuite, j’ai des bases de données  assez complète de la sphère Magento en France, ca pourrait permettre de faire un petit mailing pour les organisateurs pour pousser la chose.

Bref, si vous voulez faire un Apérogento en région, comme à Lille, Toulouse et Lyon où on m’en a déjà parlé, je suis tout à fait prêt à donner un coup de main mailing et de la visibilité pour les organisateurs ! Il suffit de me contacter : philippe[at]wikigento.com

Des plugins sympas pour Magento

Déjà Cocorico, un plugin Français pour commencer. La communauté est active, les idées fusent et les modules émergent. La société Xhéos m’informe, par l’entremise de Michaël Thieulin, que l’extension AMF service permet une intégration complète de modules Air/Flex dans le core de Magento.

Le protocole AMF s’invite donc dans le core de Magento et permet également des traitements de plus grands volumes de manière plus efficace. Faire communiquer du Flash sur le front office avec votre Backoffice, c’est partit avec AMF Webservice.

Dans la série on s’y intéresse : les plugins de performances.

L’incontournable Fooman Speedster qui concatènent les JS et les CSS pour réduire leur taille et optimiser le transfert n’est plus seul en piste puisqu’en ce moment plusieurs initiatives visent à optimiser les transferts, les requêtes, les compilations. Où se situe l’avenir ?

Dans mon idée, vous le savez, sur la compilation du PHP.

Un langage interprété ne sera jamais aussi rapide qu’un compilé. En attendant que les initiatives en ce sens (dont une très prometteuse dont je vous reparlerai) voient le jour, des plugins visent à améliorer les temps de chargement.

Bien que je n’ai pas eu encore l’occasion de les essayer, Delorum propose des Magento lignthing hyper megaspeed modules (je vais essayer de benchmarker cela). J’ai vu une autre société proposant des modules similaires à la vente mais l’URL ne me revient pas (EDIT : ah si en fait c’est ici, magento Booster). Si  vous en avez, postez en commentaire, on fera un petit benchmark pour voir qui donne quoi !

Dans les facteurs externes pouvant améliorer les performances de la bête (qui ne cesse de progresser dans son core, reconnaissons le) le moteur de recherche SolR de l’apache consortium vous donnera des recherches de la plus grande rapidité, même dans des catalogues énormes comme dans le c as du Furet du Nord (réalisé par Smile, hébergé et optimisé par NBS System). Toujours dans les « externes » (même si Zend a un unified installer avec Magento), Zend Server améliore les performances avec son Full Page Cache et ses différents mécanismes.

La vitesse comme facteur de ranking Google

Matt Cutts de Google a expliqué en novembre dernier que Google avait une forte pression interne en ce moment, notamment de l’un de ses fondateurs, pour intégrer la vitesse de chargement d’une page comme facteur de ranking.

C’est l’avènement d’une chose que l’on suspectait tous et Google l’officialise quelque part en laissant l’info filtrer publiquement. Le plus étonnant en fait c’est que ce facteur était déjà probablement pris en compte depuis des mois d’après nos tests, sans que Google ne le dise.

La question qui subiste est donc de savoir si pour posséder un bon référencement naturel il faut avoir une page qui se charge vite ou une page qui se charge plus vite que les autres. La deuxième option me parait un peu radicale par contre il y a fort à parier que les sites lents à charger se verront sanctionner dans le référencement naturel puisque, dixit un fondateur du géant, « passer de la recherche au site doit se faire aussi naturellement que tourner une page d’un livre ».

Un Bargento International

Ok on y est, on passe au dessus du gouffre et on verra bien comment ca va se passer… Bargento devient international. En gros, on invite nos copains européens qui n’ont pas la chance d’avoir un évènement local à Paris pour venir échanger avec nous tous.

La décision a été complexe à prendre, le cafouillage de dates vient en partie de là mais Bargento va en ressortir plus grand, plus fort et plus beau. Avec des fournisseurs de solutions et de compétences de tous horizons, des plugins que vous ne soupçonniez même pas, des clients des quatre coins de l’Europe !

Venez donc faire la fête internationale avec nous le 28 mai 2010, plus d’info prochainement sur Bargento.fr

]]> http://www.wikigento.com/optimisation-lampzendmagento/quelques-nouvelles-de-la-planete-magento/feed/ 6 http://www.wikigento.com/optimisation-lampzendmagento/javascript-php-performances/ http://www.wikigento.com/optimisation-lampzendmagento/javascript-php-performances/#comments Sun, 20 Dec 2009 12:52:45 +0000 Philippe Humeau http://www.wikigento.com/?p=1372 Javascript et PHP sont-ils des sources de ralentissements ?

Je vais me faire des amis avec un titre comme celui-là

Maintenant, au-delà de la provoque, menons une analyse objective.

Nous avons, de nos jours, (au moins) deux gros goulots d’étranglement lorsque nous nous adressons à un site Web :

• Javascript du coté du client
• PHP du coté du serveur.

Analyse…

Parlons de Javascript…

En général, je m’intéresse plus aux performances des serveurs que des clients au sens « navigateurs ». En réalité, la performance des clients est en générale très liée à celle des serveurs pour être plus précis. Mais le serveur ne peux pas toujours tout.

Notamment les browsers encaissent plus ou moins bien le Javascript et surtout beaucoup de Javascript.

Opera, Chrome, Firefox, Internet Explorer et leurs copains ont une tendance très nette à réagir différemment (je n’apprends rien aux développeurs Web) et surtout à réagir plus ou moins bien et plus ou moins vite en interprétation de Javascript. De plus, ces différences se cumulent avec des comportements très différents d’un browser à l’autre, notamment le nombre de requêtes concurrentes (nombres d’éléments de la page chargé en parallèle).

Tous les sites récents utilisent énormément de Javascript et ont donc une belle tendance à charger la mule, surtout quand on a plusieurs onglets d’ouverts sur plusieurs sites, on a tout de suite des machine virtuelle javascript au sein des navigateurs qui se mettent à grossir.

Ok, so what ? Qu’est ce que j’y peux me réponde les développeurs…

Eh bien beaucoup de choses en fait. Déjà, un framework c’est bien mais ca n’empêche pas de réfléchir. Faire confiance aveuglément sans regarder le dessous des cartes, c’est ce qui mène au gâchis de ressources.

Optimiser ces points (comme d’autres), c’est ce que j’appelle la « culture atari / amiga ». En gros, à l’époque, les développeurs avaient des machines identiques, des machines avec des limites et on pensait à tirer le meilleur partie du Hardware, on optimisait son programme à la goutte prêt, on passait au plus proche du matériel pour faire des choses que les concepteurs de ces machines n’avaient même pas imaginé.

De nos jours, on prend un framework, on instancie un objet et hop, derrière ca pédale mais c’est plus mon problème… Revenons à Javascript.

Des soucis de tableaux !

Il y a de nombreuses sources de maux dans Javascript, langage qui devient incontournable sur le Web depuis 5 ans. Mais lorsque les sites traitent de sujets plus complexes ou offres de nouveaux raffinement, ce qui était « une brique parmi d’autres » devient plus sensible.

Commençons par un soucis simple de Javascript : les tableaux.

Allouer un tableau en JS déclenche des mécanismes très différents d’un malloc en C. Allons y ! Sous IE, la logique de traitement est la suivante :

var my_array = new Array();

for (i = 0; i < 100000; i ++)

my_array[i] = i;

1°) Je crée un objet array qui est une table de hashage.

2°) Comme une table de hashage est un objet générique, je lui crée un attribue length (taille) et on le met à 0

3°) La boucle fait, pour chaque valeur de i

• Une conversion de i en string (chaine de caractère, en gros i= « i »)
• Ajoute un clef de hash pour chaque couple « chaine i », i
• Réajuste la valeur de length

OMG. Donc, rien que pour assigner une valeur au tableau, on a fait 3 opérations (dont deux totalement inutile si on a codé un jour en C).

Pour compléter le tableau, les allocations réelles de mémoire ne sont pas continues car les tableaux sont gérés sous la forme de « sparse » array.

C’est avantageux en terme d’usage réel de la RAM car les blocks vides ne sont pas alloués, par contre les allocations ne sont pas contigüe. Du coup, les accès à ces blocks de données ne se font pas à la suite et n’utilise pas certains mécanismes de prédiction des processeurs ou certains caches des OS. De plus les entrées du tableau ne sont pas indexées.

Bon, maintenant, on a tout pour faire une usine à gaz de compétition !

Pour résoudre ce premier point, sous IE 8, le « sparse array » est détecté comme étant dense ou non. En gros il est très peuplé ou non. Pour que l’heuristique de IE8 comprenne que c’est un « dense sparse array », il faut que ce tableau soit d’une taille explicite (en théorie mais un autre blog ne dénote pas de différence de perfs sur ce point) par contre, il faut en initialiser tous les éléments. Le défaut c’est que toute la RAM est allouée et le coté « sparse » disparait.

Sur un gros PC ce n’est pas si dramatique mais sur un téléphone portable, ouch… Du coup, initialiser l’ensemble du tableau n’est pas toujours la bonne option. Un comportement optimal serait de détecter le navigateur et de lui proposer un Javascript optimisé pour le ratio Rapidité, consommation de CPU & RAM, logique de traitement. Une sorte de librairie optimisée de gestion des tableaux, dépendante de la plateforme qui l’exécute.

En termes d’impacts c’est non négligeable !

Quelques très bon liens pour ceux que ca intéresse. Le premier blog a d’ailleurs de très bons papiers d’une manière générale !

http://www.outofwhatbox.com/blog/2009/11/javascript-array-performance-initialize-to-optimize/

http://www.outofwhatbox.com/blog/2009/12/javascript-array-performance-and-why-it-matters/

http://blogs.msdn.com/jscript/archive/2008/03/25/performance-optimization-of-arrays-part-i.aspx

PHP et les performances : plantons le décor

Revenons à nos serveurs ! Dans une infrastructure Magento, ce qui pompe dur au niveau des performances, c’est PHP et de très loin.

Il faut évidemment de la RAM pour accélérer les accès et traiter les données mais les appels PHP coutent très chers. Et c’est bien logique car le Web est coincé dans un incroyable paradoxe.

Les langages interprétés (comme PHP) sont très adaptés à certains traitements mais d’une manière générale, pour tous les traitements répétitifs ou massifs, on les évite.

L’idée c’est que dans la rapidité des langages, l’échelle est très claire :

Les compilés :

Les langages ASM/C et C++ sont compilés et (donc) très rapides. On décrit le code et cela se transforme en Opcode directement interprétables et optimisables par le processeur. Tous les caches deviennent super efficaces (L1/L2/L3 du processeur notamment) et le programme traite les données au fil de l’eau et au fil du temps. Le programme se charge en mémoire, il ne s’arrête que quand on lui demande et peut sommeiller le temps d’attendre son prochain traitement.

Assembleur : niveau processeur directement, très peu voir pas d’interprétation, vitesse maximale.

C : Le code produit par un compilateur C est très proche de l’assembleur et donc extrêmement rapide. Pour autant cela reste un langage relativement évolué, contrairement à l’assembleur on a pas à tout écrire de zéro, des librairies existent, des includes, du code un peu évolué d’une manière générale.

C++ : Un langage C évolué et Objet. On monte encore un peu dans les couches, on fait de l’objet et du fonctionnel, on en est plus à la douce barbarie redoutablement efficace de l’assembleur mais ca reste un code qui, une fois compilé, est redoutablement efficace.

Très peu souples en typage ou en gestion de la mémoire, ces trois langages compilés, pour ne citer qu’eux, sont extrêmement rapides !

La machines virtuelles :

Ce sont des programmes qui crée un environnement permettant d’exécuter d’autres programmes en leur sein. L’intérêt essentiel est de s’affranchir de la couche en dessous, en gros le programme devient portable partout. Si la VM existe pour l’environnement matériel cible, le programme tournera (presque) à l’identique sans rien redévelopper. L’inconvénient, comme toute forme de virtualisation, c’est que la VM consomme de la ressource pour créer cette couche d’abstraction, bilan ces langages ne sont pas toujours des foudres de guerre.

Java et autres JVM

Java est le plus connu des langages tournant dans une machine virtuelle, la JVM. C’est un bon langage, objet, évolué et indépendant du matériel mais il souffre de devoir être compilé tout en étant pas aussi rapide qu’un autre langage compilé.

Les « interprétés » :

Aïe. Perl, PHP et de nombreux copains à eux sont des langages dits « interprétés ». A chaque fois qu’il est lancé, le programme (test.php par exemple) est lu par un interpréteur externe (php par exemple), le fichier est parcouru, compilé à la volée quelque part, mais une fois finit, on repart de zéro. Le fichier programme à interpréter est donc lu à chaque fois et le programme qui le lit, l’interpréteur, est un programme qui est lui chargé à chaque exécution aussi.

PHP :

Un des plus célèbres. Zend au dessus est en fait composé de PHP objet évolué au sein d’un Framework, encore une couche d’abstraction. Donc si l’on compare avec nos précédents amis, Zend c’est le C++, Php le C sauf que tout cela est lu/chargé/parsé/interprété puis exécuté en continu. C’est un peu comme si on avait à se taper la compilation a chaque fois qu’on lance le programme… En fait l’image est très exacte puisque c’est quasiment exactement ce qui se passe. Bilan, les langages interprété c’est pratique, facile à maintenir et programmer, on s’affranchit de tous les aspects un peu rigoureux d’allocation mémoire ou de gestion des taches de bases mais le coût en terme de performances est énorme.

PS : Javascript est un langage de scripting interprété tournant dans une machine virtuelle (navigateur)… Tout pour gagner J

Vers un PHP compilé ?

Comme signalé plus haut, l’interprété c’est consommateur et pas adapté aux traitements récurrents. Maintenant si l’on considère une architecture d’hébergement Web, que se passe-t-il.

Admettons que le site soit en Magento, on a un framework de deuxième niveau, qui repose sur un framework de premier niveau (Zend) qui repose sur un langage interprété objet (PHP5) qui repose sur un interpréteur (Php) qui lui-même est compilé et s’adresse en assembleur au processeur.

Ajoutez un peu de virtualisation là-dessus et avant qu’une requête ne passe à travers tout ce maillage, vous avez perdu une quantité de puissance tout proprement hallucinante !

En soit, aucun reproche au fait d’utiliser PHP ou sa syntaxe, par contre, soyons clairs l’approche est juste complètement aberrante. En fait si on essayait de faire pire, le seul moyen, ca serait de faire tourner l’interpréteur php dans une JVM…

Et oui, ce n’est pas anodin mais bien dramatique. A chaque fichier PHP que vous chargez, l’interpréteur est lancé. A chaque fichier php de chargez, vous provoquez toute la cascade de compilation, d’accès disque, d’exécution. Quand un visiteur passe, il provoque donc des centaines de lancement du programme PHP qui va interpréter autant de fichiers… C’est une boucherie, une hémorragie de puissance pour finalement un problème très bête.

Le problème ce n’est pas Magento, Zend ou les fichiers PHP en soit. Sortons de la barbarie de l’assembleur, vive l’objet et tout et tout, on développe plus vite, on réutilise du code, on capitalise des librairies ! C’est l’avancement logique, l’avenir, donc ca va continuer à se développer. Par contre, pourquoi on ne compile pas tout cela ?

La charge CPU des serveurs serait juste divisée par un facteur 10 à vue de nez… C’est à ce point négligeable ? Plus clairement, sur un serveur, au lieu d’accueillir 20 000 personnes par jours par exemple, on en accueillerait 200 000. Avec le même serveur. L’approximation est un peu grossière mais pas outrancière non plus.

Le Web, qui par essence provoque des milliers de lecture et interprétation de fichier de programme, utilise un système d’interprétation, ce qui est la pire façon de faire, ce qui est le plus consommateur possible. Voici le paradoxe.

Si je me la faisais à la Yann Arthus-Bertrand, je redirais « alors pourquoi toi, homo sapiens sapiens, ne compile tu pas tes langages Web ?». Es-tu conscient des ressources gâchées par cette hérésie et de l’impact, de l’empreinte carbone, de cette approche incompréhensible ? Tu veux vraiment défoncer les puits de soleil ? Tu es un inconscient pathologique, un criminel notoire, un serial-gâcheur ? Ooops, je m’emporte… Yann (dont j’aime beaucoup le travail mais un peu moins la voix monocorde) n’irait pas jusque là !

« Pourquoi ne compile t’on pas ? », bon ok, j’arrête de faire mon YAB…

Je n’ai rien contre les développeurs, qui n’y peuvent pas grand-chose si ce n’est optimiser leur code (ca serait déjà un bon début pour certain ceci étant). Ce qui me froisse par contre, c’est que l’on a pas encore de solutions parfaitement mûres pour corriger ce point.

Des soucis assez complexes de conception sont au rendez-vous pour passer du PHP de l’état interprétable à l’état compilé. Mais ne vous y trompez pas, le Graal est au bout de la route.

Plusieurs initiatives sont en cour de développement par des gens talentueux que je ne peux qu’encourager dans cette voie : Roadsend et PHC (Php compiler mais qui paraît à l’arrêt) semblent être les leaders dans cette voie.

http://www.phpcompiler.org/

http://www.roadsend.com/home/index.php?pageID=compiler

L’autre approche possible serait un cache plus efficace, pas uniquement des opcodes comme APC mais bien des pages rendues, du résultat de l’interprétation PHP. C’est ce vers quoi se dirige Zend Server, c’est une bonne première transition mais le compilateur serait bien LA solution !

En conclusion

Je dirais que PHP et surtout le modèle interprété qui va avec et Javascript et surtout l’implémentation qui en ait faite des les navigateurs autant que dans le code de certaines pages Web, sont deux problèmes.

Ces deux axes de progression nous apporteraient un Web plus rapide, souple et agréable d’utilisation. Le réseau n’est plus réellement une limite, les processeurs sont suffisamment puissants alors deux cas sont possibles :

- Quelques personnes douées arrivent au bout de ces deux problèmes

- Tout le monde se contente de ce qu’on a, on enterre la logique d’optimisation de l’époque atari & amiga, on tue les phoques et la banquise en consommant inutilement des ressources informatiques précieuses. On compense par plus de puissance, plus de ressources consommées, plutôt que de mieux utiliser.

Un classique me direz-vous ?

]]> http://www.wikigento.com/optimisation-lampzendmagento/javascript-php-performances/feed/ 16 http://www.wikigento.com/test-bench/magento-zend-server-the-benchmarks/ http://www.wikigento.com/test-bench/magento-zend-server-the-benchmarks/#comments Wed, 01 Jul 2009 15:10:51 +0000 Philippe Humeau http://www.wikigento.com/?p=938 Bonjour à toutes et à tous,

Ce coup-ci l’article sera en anglais car c’est une publication d’un white paper rédigé à l’origine par NBS System sur les performances de Magento quand on y couple Zend server. Les tests & benchmarks sont fait entre les versions 1.2, 1.3 et 1.3 avec le flat catalog d’activé puis avec Zend Server et enfin avec Zend server incluant le page cache (version payante).

Ce white paper est en licence Creative commons paternity no commercial use, vous pouvez donc le télécharger, le modifier, le diffuser à votre convenance, sauf pour usage commercial. Celui-ci est uniquement autorisé aux sociétés NBS System, Zend et Varien. (NBS System peut autoriser explicitement l’usage commercial de ce contenu sur demande)

Vous pouvez le télécharger dans sa version PDF intégrale ici.

Magento & Zend Benchmarks

Version 1.2, 1.3 (with & without Flat Catalogs)

1. Foreword

Magento is a PHP/Zend application which intensively uses the CPU. Since version 1.1.6, each new version includes some mechanisms aimed to improve the performances. The goal is to use fewer resources for a given e-shop, which mainly means less CPU, in order to host more users with the same hardware.

One key to achieve better performances is how to optimize PHP pages generation and service. "LAMP" servers are well known and usually run Apache server with mod-php, eventually in fast_cgi mod.

Zend, the PHP Company, made a specific server (Zend Server), which includes a web application stack that (among other things) improves application performances through page caching and opcode reorganization & acceleration.

Apache and Zend Server is an alternative to the usual Apache and mod-php to run Magento, the goal of theses studies & tests is to qualify and estimate the performances added by the use of this software.

Many thanks to Yoav Kutner (Varien's CTO) for providing us with prefilled catalogs for 1.2 and 1.3 version of Magento. Thanks goes as well to Zend labs for providing help in configuration and tweaking of the Zend Server as well as explaining the in depth mechanism of the solution.

2. Methods & tools used

The benchmarks were done using siege (2.66-2), with different numbers of simultaneous threads (5, 10, 20 and 40). Each thread opens a connection to the web server, request a page, and start again as soon as the page is fetched.

Tests were run over 5 minutes each; average pages retrieved was counted for this benchmark.

Two kinds of tests were done: the first one is the simplest; we only load the main page in loop, as fast as possible.

The second test is based on logs produced by a visit, loading all the data the browser collected (including css, js, images ...). As loading a single page would usually load multiple elements, the number displayed is much higher than the number of pages that would be actually seen by visitors.

(18 pages viewed by the user, for 91 items downloaded, a ratio around 5)

All results were obtained on the same hardware and operating system, for testing purposes, no reverse proxy was active during the benchmarks but APC code cache was running. This was a "standard", default environment with no special performance tweaks installed.

Hardware used

Dual Quad-Core AMD Opteron(tm) Processor 2376 (2.3GHz), 8GB Ram, 15K SAS disks. (Dell PE M605)

Software context

Operating system: Linux (2.6.27.10-grsec) on a Debian (lenny)
Web Server: Apache2 (2.2.9-10+lenny2)
PHP (mod-php): mod-php5 (5.2.6.dfsg.1-1+lenny3) / php-apc (3.0.19-2)
PHP (Zend Server): zend-pe (1.0.0-1+b47) / mod-php5-zend-pe (5.2.9+b75)

Repositories

deb http://ftp.fr.debian.org/debian/ lenny main
deb http://security.debian.org/ lenny/updates main
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb http://repos.zend.com/deb/pe pe non-free

3. Magento Versions benchmarks

Those tests were realized on an 80 000 (later called 80 k) products catalog.

Graphs represent the average number of requests successfully loaded from the server per second during the 5 minutes test.

Loading the homepage

Magento 1.3 is much faster than 1.2 showing the main page. Flat Catalogs do not help much displaying this homepage, and seems to even slow down a little under heavy loads. The performance between 1.2 and 1.3 is doubled for low charges and is still 33% higher under heavy load.

For a standard value, under a "standard" load, we can consider that +40% is a reasonable value when running a 1.3 version instead of a 1.2, at least for the homepage.

Full visit cycle

The graph shows a slightly smaller increase with 1.3 compared to 1.2 and the flat catalog mechanism give an overall benefit which greatly increases the performances.

For the records, we can reasonably choose to keep theses values in mind:

Version 1.2 -> 1.3 : +66%
Version 1.3 -> 1.3+Flat Catalog : +20%

4. Apache + mod-php VS Apache + Zend Server

Zend Server (sometimes refered as ZS later on) comes with several built-in technologies for enhancing application performance:

• Zend Optimizer+ performs byte-code optimization and caching. This speeds up PHP applications by eliminating the process of reading scripts from disk and compiling them. Zend Optimizer+ runs automatically, and installing your application on top of Zend Server (ZS) is all you need to do in order to enjoy its benefits. During the test with ZS, APC Code cache is deactivated as Zend optimizer+ is doing the same job.
• Zend Page Cache allows caching of complete PHP pages. Page Caching greatly improves the performance of web applications while maintaining dynamic capabilities through an elaborate system of caching rules that could be based on request parameters and user session data. Page Caching also has the benefit of not requiring any code changes, and can be set up from the Zend Server UI. Only the "pro" version contains this precise piece of software which definitely makes a difference as we will see in a minute.
• Zend Data Cache is a set of API functions enabling a developer to store and manage data items (PHP strings, arrays and other data) and even output elements in either disk-based cache or shared memory cache. Zend Data Cache allows for precision-guided caching when Page Caching is not an option. The provided API is easy-to-use on existing code, and in many cases a developer can skip existing code sections by simply wrapping them with caching APIs. This precise piece of software would benefit from a little remastering of the code by Varien to really achieve a full support of this functionality. If done, we can imagine selectively flushing the cache when changing some pages on the servers and not destroying the whole Magento cache thus doing a "cold cache start" after a new functionality is put online.

Note: Zend Optimizer+ and Zend Data Cache are available in the free, community version of Zend Server, while Zend Page Cache requires a licensed Zend Server (full comparison of Zend Server and Zend Server Community Edition is located at http://www.zend.com/fr/products/server/editions).

Zend Server Configuration for Magento

In the benchmark, two caching rules have been defined:
The first rule caches the JavaScript files which are dynamically merged into one request by Magento.
This simple rule results in a very substantial improvement to response times.

The second rule caches all web pages accessed by users who have nothing in their shopping carts or history (when the shopping cart is not empty or when the user history is saved, there is no point in page caching). As you can see in the screen capture below, this is accomplished by looking at $_SESSION variables and by splitting according to $_SERVER['REQUEST_URI'] in addition to the QUERY_STRING.

Finally, Zend Optimizer+ has been enabled for optimizing and caching the PHP byte-code.

As you can see, Zend Page Cache seems a very powerful feature. It needs fine tuning and better configuration, but let's see results :

Homepage / 80 000 products catalog

Load on main page doesn't prove very constructive, although, on heavy load (40 concurrent requests), Zend Server (with or without page cage) is slightly better than basic mod-php, but almost no real improvements on this test. A 5% or less win is not to be taken seriously as it is the error margin of the tests.

Full visit / 80k products

Full visit graphic speaks for itself, whatever the load, Zend Server with Page Cache and Flat Catalog make a big difference.

Comparing a 1.3 with flat catalog with a the same configuration but with a Zend Community installed instead of just APC, our server yield up to 15% more performances, just using a free edition of ZS.

If we use a full Zend server (the licensed one including the page cache) on this 1.3 flat catalog, our server goes up to 30% more performances!

Mod PHP + APC -> ZS: +15%
Mod PHP + APC -> ZS licensed edition: +30%

5. Response time

Homepage / 80k products

This graph show response time on the homepage measured during a load. No match on this test, under a good load, ZS, community or licensed edition, gives up a 35% boost in the load time, good to take.

Full visit / 80k products

Page Cache provides a better response time over a full visit of the site, even under very heavy load. As the difference remains thin, I would conclude it to be identical in that condition. However, the benefits of the page cache under a standard load remains a must have. Once again, a 35% win is to be considered as a reference value under a good load whether you are using a community or licensed version.

Under medium or light load, the page cache is giving a lot more power than the community edition can do. This strange result is probably mainly due to the page cache mechanism which prove to be not that efficient under heavy load because the system is using its resource in a different way.
We didn't had time to check if it was a False cache sharing effect on L2 or L3 processor cache or a Linux or ZS issue but the test has been runned several times yielding the same results.

So keep in mind that the benefits of the ZS Page cache mechanism is going to be less and less active as the server load gets high. Under a usual load, a reasonable load lets say, the Page Cache algorithm gives a nice boost to the loading time, driving it down for ~40%.

6. Additional technical details about the tests

Sample data

All tests were run with generated sample data (provided by Varien)

Description of the tests

Main page test

Each concurrent thread loads the main page, without storing the cookies to simulate simultaneous users.

Full visit test

We have a list requests based on a visit done with a real browser. Each concurrent thread loads each item one after another as fast as possible, and restarts after deleting all its cookies. This simulates simultaneous users, except that simultaneous.

List of requested pages for the 80k database (with POST information when it applies):

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

<span style="font-size: xx-small;">http://test80k/
http://test80k/skin/frontend/default/default/favicon.ico</span>
<span style="font-size: xx-small;">http://test80k/js/index.php?c=auto&amp;f=,prototype/prototype.js,prototype/validation.js,scriptaculous/builder.js,scriptaculous/effects.js,scriptaculous/dragdrop.js,scriptaculous/controls.js,scriptaculous/slider.js,varien/js.js,varien/form.js,varien/menu.js,mage/translate.js,mage/cookies.js
http://test80k/skin/frontend/default/default/css/reset.css
http://test80k/skin/frontend/default/default/css/menu.css
http://test80k/skin/frontend/default/default/css/print.css
http://test80k/skin/frontend/default/default/css/clears.css
http://test80k/skin/frontend/default/default/css/boxes.css
http://test80k/skin/frontend/default/default/images/body_bg.gif
http://test80k/skin/frontend/default/default/images/logo.gif
http://test80k/skin/frontend/default/default/images/btn_mini_search.gif
http://test80k/skin/frontend/default/default/images/mini_search_bg.gif
http://test80k/skin/frontend/default/default/images/nav_bg.jpg
http://test80k/skin/frontend/default/default/images/nav_divider.gif
http://test80k/skin/frontend/default/default/images/main_container_bg.gif
http://test80k/skin/frontend/default/default/images/shop_access_pipe.gif
http://test80k/skin/frontend/default/default/images/base_mini_head_bg.gif
http://test80k/skin/frontend/default/default/images/media/col_left_callout.jpg
http://test80k/skin/frontend/default/default/images/header_top_container_bg.jpg
http://test80k/skin/frontend/default/default/images/icon_table.gif
http://test80k/skin/frontend/default/default/images/icon_newspaper.gif
http://test80k/skin/frontend/default/default/images/icon_tag_green.gif
http://test80k/skin/frontend/default/default/images/icon_basket.gif
http://test80k/skin/frontend/default/default/images/media/col_right_callout.jpg
http://test80k/skin/frontend/default/default/images/footer_info_separator.gif
http://test80k/skin/frontend/default/default/images/main_bg.gif
http://test80k/category-736
http://test80k/skin/frontend/default/default/images/layered_nav_head_bg.gif
http://test80k/skin/frontend/default/default/images/layered_nav_narrowed_category_heading.gif
http://test80k/skin/frontend/default/default/images/narrow_by_set.gif
http://test80k/skin/frontend/default/default/images/narrow_by_dd_bg.gif
http://test80k/skin/frontend/default/default/images/pager_arrow_right.gif
http://test80k/skin/frontend/default/default/images/sort_asc_arrow.gif
http://test80k/media/catalog/product/cache/1small_image/135x135/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/small_image.jpg
http://test80k/skin/frontend/default/default/images/pager_bg.gif
http://test80k/category-736?attribute_864=306
http://test80k/skin/frontend/default/default/images/list_remove_btn.gif
http://test80k/skin/frontend/default/default/images/narrow_category_bg.gif
http://test80k/skin/frontend/default/default/images/narrow_by_li_by.gif
http://test80k/category-736?attribute_864=306&amp;price=3%2C100
http://test80k/category-736?attribute_864=306&amp;price=3%2C100&amp;p=2
http://test80k/skin/frontend/default/default/images/pager_arrow_left.gif
http://test80k/category-736?attribute_864=306&amp;price=3%2C100&amp;p=3
http://test80k/category-736/gtx14049.html
http://test80k/js/index.php?c=auto&amp;f=,prototype/prototype.js,prototype/validation.js,scriptaculous/builder.js,scriptaculous/effects.js,scriptaculous/dragdrop.js,scriptaculous/controls.js,scriptaculous/slider.js,varien/js.js,varien/form.js,varien/menu.js,mage/translate.js,mage/cookies.js,varien/product.js,calendar/calendar.js,calendar/lang/calendar-en.js,calendar/calendar-setup.js
http://test80k/js/calendar/calendar-win2k-1.css
http://test80k/media/catalog/product/cache/1/image/265x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/image.jpg
http://test80k/skin/frontend/default/default/images/product_essential_bg.gif
http://test80k/skin/frontend/default/default/images/product_collateral_bg.gif
http://test80k/skin/frontend/default/default/images/dotted_divider.gif
http://test80k/skin/frontend/default/default/images/icon_tag_add.gif
http://test80k/checkout/cart/add/uenc/aHR0cDovL3Rlc3RtMTIudGVzdC5uYnMtc3lzdGVtLmNvbS9jYXRlZ29yeS03MzYvZ3R4MTQwNDkuaHRtbD9fX19TSUQ9VQ,,/product/67952/ POST product=67952&amp;related_product=&amp;qty=
http://test80k/checkout/cart/
http://test80k/js/index.php?c=auto&amp;f=,prototype/prototype.js,prototype/validation.js,scriptaculous/builder.js,scriptaculous/effects.js,scriptaculous/dragdrop.js,scriptaculous/controls.js,scriptaculous/slider.js,varien/js.js,varien/form.js,varien/menu.js,mage/translate.js,mage/cookies.js,varien/weee.js
http://test80k/skin/frontend/default/default/images/btn_proceed_to_checkout.gif
http://test80k/skin/frontend/default/default/images/btn_trash.gif
http://test80k/media/catalog/product/cache/1/thumbnail/75x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/skin/frontend/default/default/images/success_msg_icon.gif
http://test80k/skin/frontend/default/default/images/icon_asterick.gif
http://test80k/skin/frontend/default/default/images/icon_lorry.gif
http://test80k/skin/frontend/default/default/images/data_table_th_bg.gif
http://test80k/skin/frontend/default/default/images/base_mini_actions_bg.gif
http://test80k/category-736/gtx14049.html
http://test80k/media/catalog/product/cache/1/thumbnail/50x50/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/category-1497
http://test80k/media/catalog/product/cache/1/small_image/135x135/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/small_image.jpg
http://test80k/category-1497?attribute_864=305
http://test80k/category-1497/npt25-a.html
http://test80k/media/catalog/product/cache/1/image/265x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/image.jpg
http://test80k/checkout/cart/add/uenc/aHR0cDovL3Rlc3RtMTIudGVzdC5uYnMtc3lzdGVtLmNvbS9jYXRlZ29yeS0xNDk3L25wdDI1LWEuaHRtbD9fX19TSUQ9VQ,,/product/25870/ POST product=25870&amp;related_product=&amp;qty=
http://test80k/checkout/cart/
http://test80k/media/catalog/product/cache/1/thumbnail/75x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/category-3
http://test80k/media/catalog/product/cache/1/thumbnail/50x50/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/category-3?price=4%2C1000
http://test80k/checkout/cart/add/uenc/aHR0cDovL3Rlc3RtMTIudGVzdC5uYnMtc3lzdGVtLmNvbS9jYXRlZ29yeS0zP3ByaWNlPTQlMkMxMDAwJmNhdD0zNyZfX19TSUQ9VQ,,/product/4642/
http://test80k/checkout/cart/
http://test80k/checkout/onepage/
http://test80k/js/varien/accordion.js
http://test80k/skin/frontend/default/default/js/opcheckout.js
http://test80k/skin/frontend/default/default/images/opc_off_head_bg.gif
http://test80k/skin/frontend/default/default/images/opc-ajax-loader.gif
http://test80k/skin/frontend/default/default/images/btn_window_close.gif
http://test80k/skin/frontend/default/default/images/cvv.gif
http://test80k/skin/frontend/default/default/images/multi_address_box_bg.gif
http://test80k/skin/frontend/default/default/images/btn_place_order.gif
http://test80k/catalogsearch/ajax/suggest/ POST q=45
http://test80k/catalogsearch/ajax/suggest/ POST q=456
http://test80k/catalogsearch/result/?q=456&amp;x=17&amp;y=8
http://test80k/media/catalog/product/cache/1/small_image/135x135/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/small_image.jpg
http://test80k/media/catalog/product/cache/1/thumbnail/50x50/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg</span>

7. Things to test in the next benchmark campaign

Mage Compiler

When running all those tests, 1.3.1.1 version including the Mage optimizer was about to be released and an immediate 1.3.1.2 version followed and we didn't had time to include some tests around this precise point. Let's just consider the fact that this mechanism is mainly made to lower I/O jobs by "compiling" the libraries files all in one or two includes only. If your servers were already using mainly their RAM to work, the performances increase will not be that valuable. But if your servers where low on RAM or using mainly their disks, you should feel confident with using this option which can do great good to your performances!

Nginx

We didn't had the required time to consolidate the results involving Nginx + PHP tests. This solution ranked almost every time between Magento 1.3 + FC and Magento 1.3 + Zend server (without Page cache). So this combination yield average performances, not as sharp as a Magento 1.3 + Zend server or any more advanced combination.

More "customed" visits

We have used a scenario involving each time a research in the search bar of the website and some "standard" behaviors. A more precise test can be run replaying some real traffic pumped up from apache log on a real site, the customer's behaviors being more realistic even if our scenario was as logical as possible.

8. Conclusion

First, let me say that no electrons were armed or injured during these benchmarks. Perhaps one or two CTO were put under constraint and continuous coffee perfusions but all of this was intend for the greater good of E-commerce!

If you wish a more professional conclusion, let's say that using ZS community edition will only do you good and really can replace APC.

If using the licensed version, the Page cache is very efficient (under reasonable load of the servers) and can help using ~25% less machines to achieve similar hosting capacities. If your servers are billed in a "managed hosting" way, having one or two less servers billed per month can make a good difference in the budget.

About Zend Server : this software has many other great functionalities and this paper is only consider the "performances" issues, just pay a visit to Zend Website for a far more complete overview of the product.

Last but not least, creating a server with all optimizations and best practices, based on an a dual AMD 2376 with 8 Go of RAM and using ZS and page cache, you can try to reach up to ~40 000 unique visitors a day corresponding to ~2 500 Magento simultaneous session at maximum load. (if database is separated on a different server and you activate a reverse proxy like Squid or Varnish above your front web servers)
This estimation is deeply linked to the website complexity and user standard behavior but these figures are given for a "standard" site and use, you can usually also expect a ~2 seconds loading time on the homepage.

If we had to sum up a quick dirty, average table of the performances, without any details, we would give that:

© June 2009, NBS Team,

René Amirkhanian, Adrien Urban, Philippe Humeau,
you can visit us here: www.nbs-system.com
and reach us at: contact@nbs-system.com for any comments or corrections (and yes, we do hosting )

9. Creative Commons

This document is released under the creative common license "Attribution-Noncommercial-Share Alike 3.0". Only three companies (NBS System, Zend and Varien) are allowed to use it for commercial purposes.

Même si les débuts de Mage_compiler sont discrêts, cette nouvelle option est un bon signal de plus :

1°) Varien signe ici un mouvement supplémentaire dans le sens de l’optimisation des performances et depuis la 1.1.6, toutes les versions prennent cette direction. On arrive à un point où le gain cumulé approche les 35 à 70% selon les sites.

Magento est très largement plus fonctionnel et avancé qu’Os commerce, d’où la nécessité d’avoir plus de puissance pour le suivre. Rien de si illogique à cela. En version 1.0.0 on avait un facteur ~6, on en est à un facteur ~2/3. En huit mois, chapeau bas. La bonne nouvelle c’est que l’on gagne en performance, de manière continue et que ce chemin est bien un point majeur pour Varien.

2°) C’est une solution qui va permettre aux serveurs « standards » et aux petites infrastructures de gagner en performance de manière sensible.

Comment ca marche

Vous pouvez l’activer dans le back office en version 1.3.2.1 ou supérieur. Une fois ceci fait, Mage_compiler va en fait concaténer les fichiers liés à Magento en deux librairies et ainsi soulager considérablement les I/O (Input/Output) sur les disques des serveurs.

En effet, l’organisation du code en librairie et en fichiers facilite la maintenance mais complique la vie des machines. Charger un fichier commence par l’ouverture d’un handler, la sequence de lecture, potentiellement la fermeture de ce handler et ceci mutiplié par des centaines voir des milliers de fichiers. Toute économie sur ce point est donc sensible.

Mage_compiler « compile » enfin plus exactement regroupe (merge) ces nombreux fichiers afin de soulager le système de tous ces chargements.

Si l’on a une machine avec peu de mémoire et/ou des disques peu rapides, le gain sera très sensible, peut être jusqu’à 30% voir 40% car les fichiers ne peuvent rester en mémoire avec peu de RAM, il faut donc souvent les charger. Si le disque est lent, cette opération est couteuse.

Si votre infrastructure était déjà doté de serveur avec beaucoup de RAM qui ne décharge pour ainsi dire jamais des fichiers, le gain sera faible, de l’ordre de 5% maximum. De la même façon si vous avez des rolls de disques durs en 15 000 tours / minutes en SAS, il y a peu de chance que votre gain dépasse les 10%, même avec peu de RAM.

Les grands gagnants de cette version seront donc les serveurs bas ou moyen de gamme, soit dotés de peu de RAM (moins de 2 Go) soit dotés de disques lents (SATA en 7200 T/m) voir les deux.

J’espère avoir le temps prochainement de vous proposer des valeurs plus concrêtes en termes de gain de performances, après quelques benchs.

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.