Aujourd’hui un petit topo sur la latence. Première question simple : qu’est-ce donc ? D’où provient le temps d’attente, de quoi est-il composé ?

Quand je clique sur une page, entre le temps de mon action sur la page et le moment où je reçois la donnée demandée, il se passe une cascade de choses. Quel % de temps peut être attribué à chaque élément, ping de la liaison xDSL du client, chargement d’Apache, traitement php/zend, actions Magento, recherche dans la base de données, etc… ?

D’après Amazon, si 0,1s de latence me coûte 1% de CA et c’est loin d’être linéaire.

A 10 secondes de ping, c’est plus dans les 95% de CA qu’on perd ! La latence c’est un peu le pire ennemie des E-commerçant et de leurs clients. C’est le moment de flottement où je pense à autre chose qu’à acheter, où je me dis « il est lent ce site » où je me déconnecte etc…

Dans le cas de Magento, qu’est-ce qui pèse ?

Comment la diminuer globalement cette latence : où agir ?

Voici un premier schéma qui montre une architecture d’hébergement :

Ce schéma montre plus d’un point de vue logique les enchainements entre les serveurs, ce qui permet de mieux comprendre le suivant :

C’est un cas imaginaire avec un utilisateur doté d’un ordinateur et d’un browser de bonne qualité avec un hébergeur correct.

Attention, il ne faut pas croire qu’un serveur de contenu multimédia (MMA) et un reverse proxy ou un L/B augmente le total de la latence. En réalité ils diminuent la latence globale qui aurait été plus élevée mais leur coût est quand même posé. On oublie aussi trop souvent ces petits riens qui pèsent au final, les tiers : tag analytics et donc connexion (de l’utilisateur) à Google, flux rss importés etc… Selon l’endroit où sont placés ces includes et les moments auxquels intervient leur chargement, cela change beaucoup de choses pour les utilisateurs et de façon (presque) injuste pour leur appréciation de votre site.

De plus tout ce qui est représenté est informel, les valeurs varient grandement d’un surfer à l’autre, d’un hébergeur à l’autre et bien sur, d’un site à l’autre. J’ai pris ici une  »page lambda » du site, le comparateur d’article ou une recherche dans un moteur prendra beaucoup plus sur la zone « requêtes SQL » par exemple.

Le point sur lequel les développeurs et les hébergeurs peuvent avoir un rôle décisif, c’est la partie en bleu/cyan et ca tombe bien, en Magento, c’est là que se situe le maximum du « poids » et donc de latence :

Les requêtes SQL et l’interprétation PHP représentent entre 60 et 80% du temps d’attente…

Donc : c’est bien là qu’il faut agir

Agir en optimisant les infrastructures Hardware (voir précédents posts TFMFG, ~20% de variations de perfs) agir en optimisant les configurations des serveurs/services (voir précédents posts, jusqu’à ~30% de variations de perfs) et agir en optimisant son code (gain de 20 à 100% selon la qualité du code) tout en utilisant une version up to date de Magento (~40% de gains entre une 1.0.0 et une 1.2).

A bientôt pour de nouvelles aventures Magentesques.