Notre test a un fallback HTTP si le port 8080 n'est pas accessible, comme le fait Speedtest.net (mais en mieux ). Mais c'est une vraie galère à mettre en place et les résultats sont très variables en THD d'un browser à l'autre.

Les résultats de Speedtest.net étaient donc, selon vous, tout aussi voire plus « très variables » en THD à l'époque où l'utilisation des sockets Flash par leur moteur de test n'était pas aussi généralisée (puisque vous déclarez faire mieux) ? Il me semble qu'au contraire, c'était réputé plutôt stable avec les bons serveurs.

Au passage, ces pourcentages sont à relativiser : n'y aurait-il pas, par exemple, une corrélation entre le fait que le navigateur soit relativement à jour, et l'âge et donc la puissance de la machine derrière (parce que la vitesse de la carte réseau ou encore les performances globales sont très importantes pour un test THD en Flash ; d'ailleurs, pour ce qui est de la consommation de ressources, sur ma machine qui a quelques années, je n'ai pas besoin de faire votre test pour que votre site soit complètement inutilisable sans bloqueur de pubs à cause du swap qu'il déclenche) ?

Flash bénéficie d'une présence de 95% sur les postes.

Et la version de Flash que votre test requiert (parce que la dernière supportée par mon navigateur+OS ne semble pas être assez récente) ?

A 76% on est encore loin, très loin ! Et puis tout le monde ne met pas à jour son browser malheureusement, donc on doit en réalité être encore plus loin !

Le site que j'ai cité se base sur des statistiques réelles d'usage des navigateurs par version venant de StatCounter. Pourquoi ne serait-ce pas justement représentatif ?

Merci Ralph pour tes tests,

on dirait qu'OVH a des soucis en ce moment.
Avec Orange aussi c'est pas terrible !

On utilise 8 threads en up et en down. Le test de vivien utilise davantage de threads, ça peut expliquer (en partie ?) la différence de débit en download je suppose. Le souci c'est qu'on doit aussi faire un test qui convient à toutes les connexions, et pas uniquement des connexions FTTH, donc 16 threads en ADSL 512k c'est violent quand même Cela dit on en est qu'au début, il y aura probablement des améliorations à faire, notamment pour ajouter des threads en cours de test...

faites un test en ligne de commande

Oui, pourquoi pas Le truc c'est que s'il n'est pas Open Source vous l'utiliserez quand même ?

Au moins avec de l'open-source, on peut voir la méthodologie de test et en discuter, voir l'améliorer, je ne vois pas que qu'il y a d'intéressant à le "cacher" et bon, ce n'est pas si il n'existait pas Wireshark =)

Rien ne vous empeche a laisser ouvert les procedures de uploads et DL et de voir si le commandline n'explose pas vos connexions serveurs....

L'appli communique avec notre SI qui centralise les requêtes et gère la charge de notre réseau de serveurs. Cette partie là ne peut pas être OpenSource (code d'accès, cryptage des infos etc.), et on veut garder le contrôle de la bande passante le plus possible... c'est ce qui garanti la pertinence des tests et nous permet d'adapter notre réseau de serveurs au trafic qu'il doit supporter...

C'est très loin d'être une garantie. Tant que ça se passe côté client ça peut être reversé, d'ailleurs les applications Flash ça se reverse très bien, le bytecode AS3 décompilé donne généralement quelque chose de très lisible et proche du code original. Et souvent c'est reversé, d'ailleurs en faisant une recherche Google vous trouverez un bon nombre de scripts permettant de générer de faux résultats Speedtest.net.

Si vous faîtes reposer des informations censées être critiques vis-à-vis de la sécurité de votre système sur du code exécuté côté client, alors ce n'est pas de la sécurité, c'est de la fausse sécurité.

Je confirme ça se reverse très très bien avec des outils.. opensource en plus !