C’est bien connu, je suis un SBF (Sans Blog Fixe). Éric, en mai dernier, m’avait déjà ouvert son blog afin d’y évoquer une sombre histoire d’horloges. Anthony m’a donc, à son tour, aimablement ouvert un compte ici, afin que je puisse publier un nouveau billet. Il sera, une fois encore, question de WebPageTest. Cependant, rien de vraiment technique pour cette fois. Mais ce billet vous permettra, je l’espère, de mieux tirer parti des serveurs et mener à bien vos mesures dans des conditions optimales. A ce titre, je voulais, tout particulièrement, rappeler quelques points, parfois du domaine du bon sens, avant de cliquer sur le bouton « START TEST » 🙂
Pending Tests
Avant de soumettre un test, il peut être intéressant de vérifier l’état de la file d’attente. Oui, c’est du bon sens. Gardez en tête que cette file est du type FIFO (First In, First Out). Le nombre de tests en attente est visible avant même de soumettre le votre (à droite du bouton « Select from map »). Il est évident que choisir un serveur déjà bien occupé va impliquer d’être patient. Si vous êtes pressé, vous pouvez peut-être vous rabattre sur un autre serveur, même s’il n’est pas localisé en France. La position géographique du serveur n’aura peut-être aucune importance réelle pour vous. Sinon, vous gagnerez probablement en efficacité à soumettre votre test un peu plus tard. Ou choisissez d’aller boire un café 🙂
Reboot
Il faut savoir qu’un serveur WebPageTest redémarre périodiquement. Cela n’est pas due à une éventuelle instabilité matérielle ou même logicielle. Mais vous aviez remarqué que l’empreinte mémoire d’un navigateur, avec le temps et l’usage, à tendance à augmenter. A l’occasion, vérifiez le par vous même, en contrôlant sur votre poste de travail perso, en début et en fin de journée. C’est pareil pour un serveur WebPageTest. De mémoire, il me semble qu’un reboot intervient toutes les 790 minutes (soit 13 heures et 10 minutes…). Le serveur WebPageTest IE8 et Chrome, installé dans mes locaux chez GLOBALIS, est assez récent (Core 2 Duo E7500 @ 2.93 GHz, 3GB de RAM: vous êtes trop gâtés). Le redémarrage, à chaud, est donc assez rapide. Je dirais moins de 2 minutes. Mais la loi de Murphy n’est jamais loin. Et il doit arriver que certains tombent précisément sur cette période. Ca m’arrive aussi…
Plusieurs Runs
Une des nombreuses fonctionnalités proposées par WebPageTest permet de soumettre un test sur plusieurs runs. En clair, au lieu de se contenter d’effectuer un test unique à cache vide, puis à cache plein, il est possible de soumettre la même url plusieurs fois consécutives (10 maximum), ce qui peut être utile afin de faire une moyenne sur plusieurs collectes de mesures. Il faut bien comprendre, qu’en pratique, le navigateur visé est donc lancé une première fois (cache vide), puis une seconde fois (cache plein). Si cette opération est renouvelée 5 fois, on se retrouve donc avec 10 ouvertures / prises de mesures / fermetures du navigateur. Ce genre de tests à tendance à engorger la file d’attente, surtout si la page est complexe ou s’il sagit d’un site à la con (veuillez m’excuser, mais vous n’imaginez pas ce que je vois passer quasi quotidiennement…) du genre codé avec les moufles ou saturé de bandeaux de publicité…
A noter que 2 ou 3 tests en pending peuvent cacher, dans le lot, un test sur plusieurs runs (Murphy, encore). Bon, dans la pratique, ça reste assez rare, mais cela peut arriver.
J’en profite aussi pour vous suggérer de réfléchir à 2 fois si vous avez des velléités de lancer plusieurs runs. S’il vous plait, faites le à l’occasion d’une moment d’accalmie, ou mieux, le soir. Evitez les heures de pointes, en journée. Vous contribuerez ainsi à fluidifier le traffic 🙂 Donc merci pour les autres.
Les opportunistes… et les boulets…
Et oui, ils sont partout et les serveurs WebPageTest ne sont pas épargnés. Je donnerais 2 exemples.
A propos des opportunistes, j’évoquerais le cas de Cloud Harmony et son Cloud Speed Test, qui effectue quotidiennement des tests réseaux afin de mesurer tout un tas de choses (traffic montant et descendant, requêtes DNS, temps de latence, etc.) depuis différentes zones géographiques. Du moins, c’est la lecture que je fais de leur usage des serveurs WebPageTest. Après tout, quoi de plus simple que de passer par la nébuleuse de serveurs WebPageTest, répartie à travers le monde ? C’est même assez filou. Bon, Cloud Harmony ne semble pas trop abuser de la chose. Et Patrick Meenan, qui gère l’infrastructure globale de WebPageTest, est au courant. Cloud Harmony semble passer par l’API de WebPageTest et profiter des périodes d’accalmie pour lancer ce test. Mais celui ci prend néanmoins du temps…
Quant aux boulets, j’évoquerais le cas, assez récent, de quelqu’un ayant lancé un test pointant vers un site nécessitant une identification/authentification HTTP. Brillante idée ! Le test, à cache vide, prenait donc fin, sans collecte de mesure possible, après un timeout de 5 minutes. Idem à cache plein. Et voilà 10 minutes de monopolisées pour rien avec probablement un utilisateur déçu, trépignant derrière son écran, sans oublier celles et ceux qui patientaient derrière…
Pour finir…
Voilà ! Rien de transcendant mais ces explications vous aideront, je l’espère, à bien comprendre et gérer vos tests futurs et à mieux réguler le traffic. Evidement, je reste dispo, en particulier via Twitter (@fauveauarmel) si vous observez des dysfonctionnements ou autres, sur les instances IE8 et Chrome, que je gère. Ma réactivité pour résoudre un problème potentiel n’est pas garantie, j’ai aussi un métier à coté, mais je tente de rester attentif 🙂
2 Responses to Du bon usage des serveurs WebPageTest