Auteur Sujet: NSpeed: nouveau projet de mesure de débit  (Lu 66617 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 48 311
    • Twitter LaFibre.info
NSpeed: nouveau projet de mesure de débit
« le: 08 février 2020 à 12:41:15 »
Je vais aussi développer un outil pour remplacer IPerf3 si vous avez des idées & demandes c'est le moment.

Je me demande si il est pertinent de se lancer sur un nouvel outil coté serveur.

Je verrais plus un outil de test de débit en ligne de commande qui utilise un serveur web classique (Apache2 / Nginx) pour tester les débits.

Un serveur web classique à de nombreux avantages sur un outil dédié :
- Robustesse (vs plantage régulier quand l'usage est un peu exotique avec iPerf3)
- Nombreux flux et clients en parallèle (vs 1 client max par port avec iPerf3)
- Chiffrent représentatif (vs pas de chiffrement avec iPerf3)
- Prise en charge de http/2 et les nouvelles technologies...

Le test de débit se fait en téléchargeant de gros fichiers comme le propose https://bouygues.testdebit.info/ et en upload en recevant le flux envoyé par le client (comme cela fonctionne bien avec curl)

Le gros manque pour exploiter pleinement un serveur web pour faire des tests de débit, c'est le coté client.

Il y a bien curl qui permet de faire un test sur une durée fixe (Réaliser un test de débit descendant ou montant avec CURL sous Linux) mais les débits sont affichés en Mio/s, pas de possibilité d’exclure le slow start, pas de possibilité de multithread et le test upload est peu performant et nécessite d'avoir un gros fichier sur le client. Il serait bien aussi de pouvoir changer de port TCP pour faire des tests de neutralité.

Bref, je pense qu'il serait plus intéressant de faire un client efficace que de faire un nouvel outil coté serveur.

kgersen

  • Modérateur
  • Abonné Orange Fibre
  • *
  • Messages: 9 297
  • Paris (75)
Mesure de débit - nouveau projet
« Réponse #1 le: 08 février 2020 à 14:00:47 »
Je me demande si il est pertinent de se lancer sur un nouvel outil coté serveur.

Bref, je pense qu'il serait plus intéressant de faire un client efficace que de faire un nouvel outil coté serveur.


Oui je n'avais pas l'intention de réinventer la roue ou un protocole comme celui Iperf mais d'utiliser http, https, http/2 et http/3/quic.

Le code client pourra télécharger / uploaded vers n'importe quel serveur web. Ca permettra de réaliser des tests avec plusieurs serveurs différents en meme temps ce qui est impératif pour tester du 10G sur Internet.

Le code coté serveur sera donc un serveur web mais je ne crois pas que apache/nginx/caddy ou autre soient des bons candidats pour faire des serveurs de tests de débits dédiés.
L'idée est donc d'utiliser le code de serveur web existants (en Go ou en Rust) et de bâtir dessus un serveur web plus dédié a des tests de débit.

Par exemple on ne servira pas des fichiers 'réels' stockés sur disque (ou un ramdisk) comme tu fais actuellement avec testdebit.info mais des fichiers généré a la volée comme fait httpbin. Au lieu d'avoir un ensemble fixé de fichiers de tests (100M, 1G, 5G, etc) et d'extensions le client pourra demandé ce qu'il veut a l'octet pres et pourra 'post' ce qu'il veut. On pourra aussi mettre des limites coté serveurs voir une file d'attente.

L'avantage d'utiliser ce code serveur est d'avoir aussi le crosstalk, la charge cpu  et plusieurs autres info non dispo quand on  utilise apache/nginx/caddy/etc.

Il va de soit que le code client est plus important et sera le premier truc à faire puisqu'il peut fonctionner seul sans le code serveur.
Le code serveur est en plus et viendra après,  pour faire des mesures plus précises (ou des tests lan ce qui est mon intérêt 1er) et générer des statistiques pour faire des graphes.
« Modifié: 08 février 2020 à 22:07:09 par kgersen »

vivien

  • Administrateur
  • *
  • Messages: 48 311
    • Twitter LaFibre.info
Mesure de débit - nouveau projet
« Réponse #2 le: 08 février 2020 à 14:10:48 »
Remonter la charge réseau est intéressante. La charge CPU ou Ram est peu intéressante dans mon cas car l'utilisation est faible, même dans le cas de trafic https en 10 Gb/s, que ce soit sur une ou plusieurs connexion TCP. Pour un test monothread en https, il faut qu'un seul cœur soit capable de traiter le trafic, mais c'était déjà le cas sur la génération précédente de serveur que j'avais.

Peut-être créer un sujet dédié... le jour où on souhaite retrouver l'info au milieu de ce sujet, ce sera pas simple (je peut aussi séparer les messages pour en faire un nouveau sujet)

robin4002

  • Abonné RED by SFR fibre FttH
  • *
  • Messages: 895
  • Strasbourg (67)
Mesure de débit - nouveau projet
« Réponse #3 le: 08 février 2020 à 20:13:13 »
kgersen tu comptes faire ce projet en opensource ?
Je cherchais justement une idée de projet concret pour mettre en pratique du rust (ça fait quelques mois que j'avance progressivement sur la doc), du-coup je souhaiterai contribuer au projet.
Pour le code client je suppose qu'il faudra développer un programme multiplateforme ? On peut aussi envisager tenter quelque chose en webassembly, il y a surement moyen de faire des tests de débit moins gourmand dans le navigateur avec cette techno.

kgersen

  • Modérateur
  • Abonné Orange Fibre
  • *
  • Messages: 9 297
  • Paris (75)
Mesure de débit - nouveau projet
« Réponse #4 le: 08 février 2020 à 21:53:37 »
kgersen tu comptes faire ce projet en opensource ?
Je cherchais justement une idée de projet concret pour mettre en pratique du rust (ça fait quelques mois que j'avance progressivement sur la doc), du-coup je souhaiterai contribuer au projet.
Pour le code client je suppose qu'il faudra développer un programme multiplateforme ? On peut aussi envisager tenter quelque chose en webassembly, il y a surement moyen de faire des tests de débit moins gourmand dans le navigateur avec cette techno.

oui surement open-source , c'est trop tot pour le langage toutefois et j’avoue que ma préférence va a Go plutôt qu'a Rust (je ne suis pas convaincu par Rust en l'état, y'a trop  'd'effet de mode' autour et un manque de recul. Les packages tiers manquent de maturité et de mise a l'épreuve).
J'ai fais des benchmarks et je continue a en faire avant de décider du langage.
L'important c'est surtout de trouver une bonne lib client http car le but n'est pas d'aller se taper l'écriture d'un client http (surtout avec http/2 et quic...). Go a une bon client HTTP de base (net/http) et une variante rapide (valyala/fasthttp), et Go a servit pour développer HTTP/2. Rust a reqwest et Hyper.rs et au pire y'a libcurl pour quasi tout les langages...c'est peut-être le mieux mais la portabilité est plus compliqué.

Webassembly n'apportera pas grand chose en terme de performance , js ou wasm c'est pareil pour ce cas d'usage. Le bottleneck c'est les limites du sandbox des navigateurs et comment ils implémentent les websockets (ou l'api fetch) car wasm n'a pas d'accès plus bas niveau que js. Franchement et ca fait un moment que je suis sur ce sujet je ne pense pas qu'on puisse fait mieux que ce que font les 'speedtest' web actuels donc ca ne sert pas a grand chose de vouloir utiliser un navigateur.

Du moins pour le code du test lui meme (aka le client http), par contre j'ai bien l'intention de faire une interface 'web' pour l'utilisateur non expert (c'est le défaut #1 des tests avec IPerf et curl). L'idée est de faire comme avec 'Electron' mais sans la lourdeur Electron: le programme n'a pas d'interface native mais expose une interface web accessible sur localhost (ou meme en réseau). Je n'ai toutefois pas encore décider quel framework web utilisé (d'autant que je déteste JS donc ca doit être du TS ou peut-être gopherjs). L'idéal sera un seul langage pour toute la stack...a ce niveau wasm peut peut-être jouer un role...

Je vais procéder par étape:

1. Client sans interface web, ligne de commande, multiplate-forme. L'équivalent de "curl" mais vers /dev/null par défaut (et optimiser pour ca) avec parallélisme et génération d'une résultat exportable (image ou graphe). Le client pourra mesurer le crosstalk, savoir quel type d'interface et type/debit (filiaire,wifi, 4g,) est utilisée , la charge cpu, etc bien plus qu'un navigateur donc. On peut meme embarquer libupnp pour connaitre le crosstalk a la box du FAI...(vu que l'API des box c'est un sujet mort ou pas utilisable).

2. Interface web sur ce client pour les utilisateurs moins avertis. Ils téléchargent un 'exe' et le lance et ca ouvre leur navigateur sur 'localhost:1234' par exemple et une interface facon speedtest va controler le .exe pour faire des tests. L'interface doit permettre de proposer une liste de tests: download d'un fichier depuis testdebit.info par exemple, de plusieurs fichiers fichiers meme temps, etc. on peut meme envisager de concevoir des "groupes d'url" a proposer.

3. Le serveur dédié qui apportera des fonctionnalités supplémentaires (j'ai pas mal d'idées a ce sujet) notamment ce qu'on fait coté client (interface, crosstalk, cpu,etc). on peut envisager de mettre le client et le serveur dans le meme .exe par la suite pour faire des tests lan ou P2P entre 2 abonnés (moyennant l'ouverture des ports/IP qui va bien).

robin4002

  • Abonné RED by SFR fibre FttH
  • *
  • Messages: 895
  • Strasbourg (67)
Mesure de débit - nouveau projet
« Réponse #5 le: 08 février 2020 à 22:09:01 »
oui surement open-source , c'est trop tot pour le langage toutefois et j’avoue que ma préférence va a Go plutôt qu'a Rust (je ne suis pas convaincu par Rust en l'état, y'a trop  'd'effet de mode' autour et un manque de recul. Les packages tiers manquent de maturité et de mise a l'épreuve).
J'ai fais des benchmarks et je continue a en faire avant de décider du langage.
L'important c'est surtout de trouver une bonne lib client http car le but n'est pas d'aller se taper l'écriture d'un client http (surtout avec http/2 et quic...). Go a une bon client HTTP de base (net/http) et une variante rapide (valyala/fasthttp), et Go a servit pour développer HTTP/2. Rust a reqwest et Hyper.rs et au pire y'a libcurl pour quasi tout les langages...c'est peut-être le mieux mais la portabilité est plus compliqué.
Effectivement il y a beaucoup de hype autour du Rust, à voir si c'est juste passager où si cela restera. Après effectivement il faut bencher un maximum comme on cherche le plus de perf. À voir en fonction du niveau d'optimisation des libs existantes et du possible impact du garbage collector de Go (mais j'ai entendu dire qu'il a été beaucoup optimisé dans les dernières versions, son impact est vraiment minime depuis).

Webassembly n'apportera pas grand chose en terme de performance , js ou wasm c'est pareil pour ce cas d'usage. Le bottleneck c'est les limites du sandbox des navigateurs et comment ils implémentent les websockets (ou l'api fetch) car wasm n'a pas d'accès plus bas niveau que js. Franchement et ca fait un moment que je suis sur ce sujet je ne pense pas qu'on puisse fait mieux que ce que font les 'speedtest' web actuels donc ca ne sert pas a grand chose de vouloir utiliser un navigateur.
Ok donc effectivement si c'est la sandbox / l'implémentation websocket il y a effectivement rien à explorer dans les autres langages.

Du moins pour le code du test lui meme (aka le client http), par contre j'ai bien l'intention de faire une interface 'web' pour l'utilisateur non expert (c'est le défaut #1 des tests avec IPerf et curl). L'idée est de faire comme avec 'Electron' mais sans la lourdeur Electron: le programme n'a pas d'interface native mais expose une interface web accessible sur localhost (ou meme en réseau). Je n'ai toutefois pas encore décider quel framework web utilisé (d'autant que je déteste JS donc ca doit être du TS ou peut-être gopherjs). L'idéal sera un seul langage pour toute la stack...a ce niveau wasm peut peut-être jouer un role...
Alors pour un electron en plus léger, il y a webview : https://github.com/zserge/webview (avec des binding pour Go inclus et pour Rust sur ce projet : https://github.com/Boscop/web-view ) Je l'ai déjà utilisé pour quelques tests et pour un petit programme de remonté de log via une ligne série au boulot, ça permet d'avoir un exécutable beaucoup plus léger comme il passe par le navigateur du système au lieu d'embarquer un chromium. Et pour la partie backend tu codes en natif au lieu du JS.
Pour le front, tu peux mettre ce que tu veux, mais vaut mieux quelque chose qui gère du polyfill ou à minima qui compile vers du JS ancien, car sous Windows ça tourne par dessous IE11 (il est aussi possible de targer edge). J'approuve Typescript, j'en fais depuis bientôt 2 an maintenant, le retour au JS est compliqué une fois habitué.

vivien

  • Administrateur
  • *
  • Messages: 48 311
    • Twitter LaFibre.info
Mesure de débit - nouveau projet
« Réponse #6 le: 08 février 2020 à 22:13:26 »
C'est vraiment un projet intéressant, surtout avec l'arrivée des connexion à 10 Gb/s, débit qui nécessite de très grosses ressources CPU pour être testé dans un navigateur web (quel que soit la navigateur et quel que soit l'outil de test).

Je pense intéressant d'en faire une version clé USB Bootable, afin de pouvoir aider une personne à vérifier un logiciel ou driver de Windows 10 bride le débit.

Breizh29

  • Abonné Free fibre
  • *
  • Messages: 408
  • Ergué-Gabéric (29)
Mesure de débit - nouveau projet
« Réponse #7 le: 08 février 2020 à 22:16:42 »
Bon courage !
Faites signe lorsqu’il y aura de quoi tester.

kgersen

  • Modérateur
  • Abonné Orange Fibre
  • *
  • Messages: 9 297
  • Paris (75)
Mesure de débit - nouveau projet
« Réponse #8 le: 08 février 2020 à 22:25:14 »
Effectivement il y a beaucoup de hype autour du Rust, à voir si c'est juste passager où si cela restera. Après effectivement il faut bencher un maximum comme on cherche le plus de perf. À voir en fonction du niveau d'optimisation des libs existantes et du possible impact du garbage collector de Go (mais j'ai entendu dire qu'il a été beaucoup optimisé dans les dernières versions, son impact est vraiment minime depuis).
Ok donc effectivement si c'est la sandbox / l'implémentation websocket il y a effectivement rien à explorer dans les autres langages.
Alors pour un electron en plus léger, il y a webview : https://github.com/zserge/webview (avec des binding pour Go inclus et pour Rust sur ce projet : https://github.com/Boscop/web-view ) Je l'ai déjà utilisé pour quelques tests et pour un petit programme de remonté de log via une ligne série au boulot, ça permet d'avoir un exécutable beaucoup plus léger comme il passe par le navigateur du système au lieu d'embarquer un chromium. Et pour la partie backend tu codes en natif au lieu du JS.
Pour le front, tu peux mettre ce que tu veux, mais vaut mieux quelque chose qui gère du polyfill ou à minima qui compile vers du JS ancien, car sous Windows ça tourne par dessous IE11 (il est aussi possible de targer edge). J'approuve Typescript, j'en fais depuis bientôt 2 an maintenant, le retour au JS est compliqué une fois habitué.
Si on fait bien la 'boucle' en Go ou autre langage avec GC, y'a pas d'allocation mémoire donc pas de GC nécessaire. J'ai tester goben ou un go-httpbin modifié par mes soins sur 10Gbits ca passe sans souci , la mémoire et le cpu s'ennuient.

Du coup niveau perf je ne pense pas que le langage fera la différence. La maillon lent est dans la stack IP de l'OS. C'est vraiment la "lib client http" qui va importer (notamment sa gestion de la boucle d'envoi/reception et ce qu'on peut modifier ou pas dedans). Et si elle est au point, si elle permet HTTP/2 et QUIC (ideal pour tester UDP).

J'avais croisé webview mais mais ce n'est pas vraiment ce que je cherche. Tout les PC desktop ont un navigateur autant en profiter plutôt que d'embarquer nous meme du 'code de rendu html' (en plus EdgeHTML est abandonné non?).

De toute facon l'interface web est a l'étape 2, ca laisse du temps pour réfléchir et faire du design.

robin4002

  • Abonné RED by SFR fibre FttH
  • *
  • Messages: 895
  • Strasbourg (67)
Mesure de débit - nouveau projet
« Réponse #9 le: 08 février 2020 à 22:35:48 »
J'avais croisé webview mais mais ce n'est pas vraiment ce que je cherche. Tout les PC desktop ont un navigateur autant en profiter plutôt que d'embarquer nous meme du 'code de rendu html' (en plus EdgeHTML est abandonné non?).
Justement webview passe par le navigateur du système, il n'embarque rien du tout ;)
Et oui EdgeHTML est en maintenance, il va être abandonnée une fois que tous les edge seront migré sur la version basée sur chromium.

Optix

  • AS41114 - Expert OrneTHD
  • Abonné Orne THD
  • *
  • Messages: 4 932
  • WOOHOO !
    • OrneTHD
Mesure de débit - nouveau projet
« Réponse #10 le: 08 février 2020 à 23:53:44 »
J'avais plus dans l'idée de développer un testeur de débit en peer-to-peer pour ne plus être dépendant d'un seul serveur par test.

kgersen

  • Modérateur
  • Abonné Orange Fibre
  • *
  • Messages: 9 297
  • Paris (75)
Mesure de débit - nouveau projet
« Réponse #11 le: 09 février 2020 à 10:33:19 »
Justement webview passe par le navigateur du système, il n'embarque rien du tout ;)

oui mais du coup ce n'est pas vraiment multi-plateforme (Windows/Linux/Mac ce n'est pas suffisant en terme de 'multi-plateforme'. Il faut aussi Android, iOS, Freebsd, voir n'importe quel OS futur).

De toute façon c'est mieux que l'exe soit indépendant du 'webview' cela permet de l'utiliser a distance sur des machines sans interface graphique. On met le client dans un routeur ou un serveur et on a l'interface sur une autre machine. C'est plus simple niveau dev et 'build' aussi.

Je ne pense pas que l'utilisateur soit gêné de voir http://localhost:1234 d'autant qu'on peut faire une PWA pour masquer l'url (a vérifier toutefois vu les contraintes de validation pour faire une PWA). On peut aussi faire juste une API REST sur  http://localhost:1234 servie par le .exe et le code html/js est ailleurs sur un serveur public et appel l'API localement via XHR. Voir un mélange des 2.

un truc du genre, 3 solutions possibles:



Mon projet s’appelle 'NSpeed' , car c'est la suite de mon vieux test HTML5 ( http://nspeed.info/ - ce domaine s'auto détruira prochainement...) qui n'a jamais abouti vraiment vu les résultats obtenus (et y'a https://github.com/librespeed/speedtest pour ceux qui veulent un test HTML5 open source & complet).

L'url sera https://nspeed.app/ et le projet sur github (projet privé pour le moment). Mais apres chacun peut hoster son build (testdebit.info notamment).
(pour ceux qui auront deviné j'ai un projet derriere plus important de service en ligne pour récolter et presenter des graphes historisés de mesures a ceux qui veulent faire tourner le client en permanence chez eux mais ca c'est l'étape 4).

« Modifié: 09 février 2020 à 10:58:16 par kgersen »