Les horloges de webpagetest

Ce billet est un premier billet (et j’espère pas le dernier) d’un auteur différent. C’est donc Armel Fauveau qui écrit ci-dessous et non l’auteur habituel. Bienvenu à lui.
— Éric.

Préambule

Suite à la proposition d’Éric, je vais vous relater une petite curiosité technique rencontrée dans le cadre de l’administration quotidienne des serveurs WebPagetest Parisiens. Pour celles et ceux qui l’ignorent, GLOBALIS héberge gracieusement le serveur IE7 de Vincent Voyer (zeroload) depuis août 2010. Et c’est en novembre 2010 que j’ai jugé utile de mettre en ligne un second serveur, cette fois sous IE8, complémentaire de celui de Vincent. Il me semblait intéressant de pouvoir disposer de deux serveurs, sous deux versions d’IE différentes. À noter également, pour l’anecdote, que ces deux serveurs ne sont pas raccordés au même fournisseur d’accès. Le serveur IE7 utilise une connexion Numéripro. Quant au serveur IE8, il utilise une connexion Free. Cela permet évidement de mieux répartir la charge et d’assurer à tous, tout du moins je l’espère, une meilleure qualité de service et de disponibilité (hors coupure électrique ou réseau, comme cela est malheureusement arrivé, mais je ne contrôle pas tout…). Voilà pour le préambule.

Une mise en route chaotique

Revenons à l’objet de ce billet. Lors de la mise en place et de la configuration du serveur IE8, un détail a rapidement attiré l’attention de quelques experts de l’optimisation Frontend. Le temps de latence associé aux requêtes DNS était curieusement long. Quand je dis long, c’est très long. Je ne parle même pas de 250 ms ou même 500 ms. Mais carrément de 1,2 s., et même parfois plus. Évidement, tout le monde a été force de propositions. Certaines judicieuses, d’autres moins… De mon coté, après un diagnostique différentiel en bonne et due forme, j’ai passé deux nuits à multiplier les tests: ré-installer l’ensemble de la couche WebPagetest, couper l’antivirus AVG que j’avais installé par précaution (en mode minimaliste), changer la passerelle pour pointer vers Numéripro en lieu et place de Free, etc. J’ai même été jusqu’à changer la carte réseau. Rien ! La machine datait de deux ou trois ans, mais la mise en place d’un serveur WepPagetest ne nécessite pas une machine dernier cri. Et puis, j’avais pris soin de ré-installer complètement une version de Windows XP SP3 dessus (avec formatage du disque au préalable). Le problème était d’autant plus étrange que, en interactif, clavier et souris en mains, aucune latence n’était perceptible en naviguant librement de sites en sites. Or, 1,2 s. de latence, ça devrait largement se ressentir et faire de la navigation une expérience douloureuse. J’ai bien accusé un bug lié à la couche WebPagetest. Mais comment le démontrer ? Les forums du site WebPagetest ne relataient rien de similaire.


Je décide donc, perplexe, de changer de stratégie et de faire une ultime opération. J’opte pour dé-packager une nouvelle machine, que j’avais en carton. J’en ai toujours… au cas ou. Celle ci dispose d’un hardware plus récent. Je ré-installe l’ensemble de la couche WebPagetest et, surprise, les temps de latence observés sont normaux. L’origine du problème reste entier, mais résolu dans l’immédiat. Je pouvais donc passer à autre chose (j’ai un métier…), même si je n’étais pas satisfait d’en rester là. Heureusement, j’allais avoir l’occasion de revenir sur le sujet quelques mois plus tard, sans m’y attendre pour autant.

Temps de latence fantaisistes, le retour…

Le mois dernier, mi avril 2011, Patrick (Pat) Meenan, à l’origine du projet WebPagetest, me contact. Il observe des temps de latence fantaisistes sur le serveur IE8 Parisien. Détail amusant, ce ne sont plus des temps infiniment longs. Au contraire, ils sont curieusement très courts. Je parle cette fois de temps tournant autour de quelques ms (moins de 10 ms). Or il faut savoir que les temps de latence observés ne peuvent être inférieurs à 50 ms. C’est le minimum. Être en dessous, même très en dessous, révèle donc un problème. Pat a, du reste, relevé un souci similaire sur un autre serveur IE8 hébergé en Angleterre. Il me demande de faire quelques tests et de vérifier quelques paramétrages. Mais là encore, rien ! Le problème persiste. Pat me demande alors, en ultime recours, s’il serait possible que je lui donne un accès RDP/VNC, ce que je fais évidement dans la minute qui suit. Il ne le sait pas encore, mais isoler, comprendre et régler le problème va prendre… tic tac tic… 3 heures :)

Une histoire d’horloge

Lorsque vous faites un ping ou un traceroute, des temps de latence sont affichés. Pour estimer ces temps, il est évident que l’outil a besoin d’une horloge de référence. Un PC en dispose de plusieurs: TSC (Time Stamp Counter), PM Timer et HPET (High Precision Event Timer) en font parties, sans oublier la classique horloge RTC (Real Time Clock). Ces horloges n’ont qu’un seul point commun: celui de mesurer des temps ou des écarts. Mais les caractéristiques différentes de l’une à l’autre. Par exemple, HPET a été architecturée par Intel et Microsoft, afin de remplacer la traditionnelle horloge RTC, moins précise. Elle se matérialise sous la forme d’un composant discret. HPET offrant une résolution temporelle très fine et bien supérieure à RTC, elle est, par exemple, utilisée afin de synchroniser des flux multimedia (nouveaux besoins, nouvelle solution hardware…). Attention cependant, HPET peut être présente au niveau hardware, mais non utilisable pour autant. Le software doit suivre également. A ce titre, l’horloge HPET n’est fonctionnelle que sous Windows Vista et versions supérieures (donc hors XP), Mac OS (Intel évidement), Linux 2.6 et FreeBSD. La minuterie TSC, quant à elle, est une horloge à haute précision directement cablée au coeur du processeur (depuis l’avènement de l’architecture Pentium). Sans rentrer dans des détails trop techniques et fatalement barbants, une mnémonique assembleur (RDTSC) permet de récupérer dans la paire de registres 32 bits (donc 64 bits en tout) EDX:EAX, le nombre de ticks écoulés depuis le dernier RESET du processeur. Le temps mesuré est donc, là aussi, très (très…) fin. Évidement, il est possible de récupérer ce temps sans passer par le langage assembleur. Windows dispose de nombreuses APIs et la fonction QueryPerformanceCounter permet d’y accéder plus simplement.

L’origine du problème et son contournement

Le problème, c’est que cette horloge TSC peut engendrer des dérives de temps, et donc des mesures fantaisistes, sur des machines disposant d’un processeur multi-coeurs lorsque, précisément, le temps entre les différents coeurs n’est pas correctement synchronisé. Il est alors possible, par exemple, d’observer un ping ou un traceroute retournant des temps curieusement longs, ou inversement faibles, voir même négatifs ! Nous y voilà ! La première machine, comme la seconde, que j’ai utilisé pour mettre en place ce serveur WebPagetest sous IE8, disposent d’une architecture multi-coeurs (je vous gâte trop…). Or l’usage de l’horloge TSC, sur une telle architecture, peut engendrer des erreurs de chronométrage. Microsoft recommande, du reste, d’utiliser prioritairement d’autres minuteries lorsqu’une application invoque la fonction QueryPerformanceCounter. WebPagetest mesurant fort logiquement tout un tas de temps, nous étions précisément confronté au phénomène.

Rester donc à contourner le problème en forçant l’usage d’une autre horloge. Sous Windows NT jusqu’à la version 2003 (donc hors Vista, Windows 7 et Windows Server 2008), un programme est lancé à l’amorçage: NTLDR (pour NT Loader). Ce programme dispose également d’un fichier de configuration: boot.ini. C’est assez similaire, pour les utilisateurs de Linux, au principe de GRUB ou de LILO (je suis un ringard, je préfère et reste fidèle à LILO et à Slackware, mais je m’égare…). Il est donc possible, via le fichier boot.ini, de tuner un certain nombre de choses, dont cette problématique de minuterie. En ajoutant /usepmtimer, il est alors demandé à Windows d’utiliser explicitement l’horloge PM Timer en lieu et place de TSC. Il doit être possible, également, de jouer au niveau du BIOS. Mais c’est la solution via l’ajout de /usepmtimer dans le boot.ini que Pat a retenu et qui a permis de résoudre le problème.

Conclusion

Voilà, j’espère avoir comblé la curiosité de certains sur le mystère des dérives de temps que vous aviez parfois observé sur le serveur WebPagetest IE8 Parisien. Cela sera peut-être utile à d’autres. Quant à Pat, il a eu l’occasion de manipuler un Windows XP SP3…en français et lui comme moi, d’en apprendre plus sur les horloges :) Ne l’oubliez jamais, la vérité est souvent ailleurs, ne croyez pas aveuglément les mesures, restez toujours pragmatique et gardez l’esprit critique. Bons tests à toutes et à tous !

Pause

J’ai toujours déclaré que je suivrai le rythme d’écriture qui me plait, ne me forçant pas à écrire quand je n’en ai pas envie. Ces derniers mois il y a donc eu peu de billets, traduisant une situation personnelle qui occupe suffisamment mon esprit pour que je ne me disperse pas trop.

Il est temps pour moi de faire une pause. Je l’espère courte, elle sera peut être longue, vous verrez, et moi aussi.

Je reste focalisé sur le sujet, n’hésitez pas à m’envoyer des liens, je peux toujours vous proposer audits, formations ou accompagnements professionnels sur ces sujets, avec une expertise de pointe, mais l’écriture sur mon temps personnel n’est plus d’actualité à très court terme.

Bonne continuation et merci à tous ceux qui m’ont suivi ici. J’espère vous revoir quand je déciderai de reprendre, que ce soit dans deux semaines ou dans plusieurs mois.

Automatisation de Yslow

La prise de conscience sur le sujet des performances web évolue. Beaucoup d’équipes ont désormais appliqué quelques recettes de base, ou ont au moins un item dédié dans la liste des choses à faire.

Il reste toutefois à passer une phase d’industrialisation. Lancer Yslow tous les mois à la main n’est pas toujours idéal. Cela implique de reporter des résultats manuellement et du coup de ne le faire que pour un nombre limité de pages. On se retrouve aussi à devoir trier les métriques pour y associer une priorité et ne pas se retrouver à devoir tout faire immédiatement.

Une approche pragmatique voudrait qu’on puisse automatiser Yslow et s’occuper régulièrement des points et des pages les plus prioritaires. C’est ce que vous propose Yslow : Lire la suite

Experience de voici.fr

J’aime bien apporter un peu de retours d’expérience, pour montrer que toute la théorie fonctionne aussi en pratique. Certes il y a Yahoo!, Google, Amazon, mais ce sont des trop gros sites pour que le développeur moyen se sente impliqué.

Alors voilà, Charles-Christian Croix nous parle un peu de ce qui a été réalisé sur Voici.fr. La première étape se fait via une configuration des entêtes HTTP de cache de ezPublish puis une configuration de mod_gzip sur Apache, et enfin par une configuration de mod_expires, toujours sur Apache. Il fait de même plus tard sur une installation Dotclear. Lire la suite

Priorisation des onglets sur Firefox

Je ne donne pas de nouvelles mais je suis toujours de près toutes les actualités liées à la performance. En ce moment il y a peu d’articles techniques qui font de réelles avancées. L’innovation vient plutôt du navigateur, et Mozilla fait un sacré travail.

Il y a une dizaine de jours j’ai vu l’annonce d’une fonctionnalité qui me semble couler de source. J’avais longtemps pensé que c’était le cas sur tous les navigateurs, et mêmes sur tous les systèmes d’exploitation : donner plus de ressources à l’onglet ou à l’application en cours d’utilisation. Cela semble logique mais ce n’était pas encore le cas.

Jusqu’alors le navigateur gère ses files de téléchargement, premier entré premier sorti, ou presque. Ceux qui ont comme moi l’habitude d’ouvrir des dizaines d’onglets en parallèle connaissent bien le problème. Assez vite le navigateur devient inutilisable car trop de pages sont en chargement. La navigation principale s’en ressent, quand elle n’est pas totalement bloquée.

La solution ? Paul O’Shannessy nous propose une priorisation des onglets et des requêtes réseaux qui en découlent. C’est génial. Ça ne coute rien, ça ne demande pas une amélioration des performances du navigateur réseau, ça n’a quasiment aucun effet négatif, mais c’est une avancée réelle pour l’utilisateur, comme je les aime. Lire la suite

Pngrewrite sous linux

Je fais encore le tour des outils de compression d’image pour faire la comparaison et trouver le bon compromis entre ressources consommées et efficacité. Un de mes problème c’est punypng qui annonce des performances exceptionnelles mais qui ne détaille pas son fonctionnement et ne propose même pas d’API. Je vérifierai leurs affirmations et tenterai de m’en approcher mais en attendant je fouille.

Un des outils que je regarde c’est pngrewrite. La rumeur voudrait qu’il ne gagne pas grand chose mais qu’il est capable de le faire même après un passage par optipng ou pngcrush. Bref, un petit ajout rapide, juste pour grappiller un peu plus.

Je vais vérifier tout ça là aussi, mais en attendant le code proposé sur le site officiel ne compile pas sur mon linux récent. Pour ceux qui ont le même problème, la distribution gentoo a un patch disponible. Il suffit de le télécharger là où vous aurez décompacté le code source de pngrewrite et de lancer patch -p0 < pngrewrite-1.3.0-gcc44.patch puis de taper l’habituel make.

Voilà, maintenant vous savez.

J’aurai bien fait des paquets Ubuntu pour pngrewrite et pngout mais je ne trouve pas la licence du premier et le second interdit explicitement de reditribuer l’exécutable résultat. Si j’ai le courage je tenterai peut être des paquets « tricheur » qui téléchargent sur Internet lors de leur installation mais ça perd un des intérêts.

Performance ressentie avec Mozilla

Ici je m’attache beaucoup aux chiffres : temps de chargement complet, latence, nombre de composants, etc. J’ai besoin de convaincre et seuls les chiffres ont l’objectivité nécessaire pour pouvoir travailler avec des gens non convaincus.

Toutefois, une fois dépassé ce stade il faudrait se détacher un peu des chiffres pour parler de performance ressentie et pas toujours de performance mesurée. Parfois peu importe la durée de l’attente si on voit que nous progressons régulièrement et que l’attente n’est pas frustrante en elle même. C’est vrai aux caisses d’un supermarché comme sur une page web.

Les éditeurs de navigateurs l’ont bien compris. Ils jouent sur les indicateurs de chargement et sur l’interface pour donner une impression de vitesse à l’utilisateur. L’impression de vitesse est l’unique chose qui compte pour ce dernier, même si au final ça veut dire que les temps mesurés sont objectivement plus lents.

C’est avec cette idée en tête que je vous propose de lire le document de Mozilla à propos de la performance perçue. On y retrouve certaines techniques à mettre en oeuvre sur les versions actuelles ou futures de Firefox. Le document mériterait une traduction tellement il fourmille d’idées, dont certaines sont lumineuses.  Je vous en retransmet certaines, avec mes commentaires. Lire la suite

Page lente = taux d’abandon important

On en parlait il y a deux semaines dans le résumé de Steve Souders mais il semble que la statistique mise en avant avait peut être quelques défauts. On en a reparlé entre temps avec un joli graphique en camembert, et on a encore reparlé de la pertinence de la statistique.

Il nous reste deux statistiques qui vont encore dans le même sens : Yahoo! affirment que sur leur site auto, ajouter 400ms au chargement de la page fait monter le taux d’abandon de 5 à 9%. Akamaï affirment eux qu’au delà de 4 secondes, le taux d’abandon devient vraiment important.

Encore des chiffres

C’est Artur Bergman qui nous donne encore du grain à moudre dans le dernier slide de sa présentation à l’OSCON. Il a mené une étude à l’aide de Google Analytics pour croiser le taux de rebond et le temps de chargement de la page. Les résultats sont tels que je les attendais : une courbe assez claire, presque une droite, qui confirme que les pages lentes sont de natures à faire fuir les utilisateurs. Lire la suite