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

0 Membres et 1 Invité sur ce sujet

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #108 le: 18 mai 2021 à 16:47:02 »
et ce n'est pas un souci de cpu on dirait:

HTTPS:
4:38PM WRN nspeed listening on https://127.0.0.1:7333 job=0
4:38PM --- |  4|  2|  2|  2|  1|  1|  6|  0|, active jobs: 2 / active goroutines: 7
4:38PM --- | 33| 38| 31| 37| 43| 41| 36| 32|, active jobs: 2 / active goroutines: 12
4:38PM --- | 39| 36| 36| 32| 34| 39| 33| 37|, active jobs: 2 / active goroutines: 11
4:38PM --- | 38| 41| 40| 35| 33| 40| 33| 27|, active jobs: 2 / active goroutines: 12
4:38PM --- | 35| 36| 39| 37| 32| 33| 37| 36|, active jobs: 2 / active goroutines: 12
4:38PM --- | 37| 27| 39| 34| 39| 40| 43| 36|, active jobs: 2 / active goroutines: 11
4:38PM --- | 35| 34| 34| 32| 27| 36| 34| 41|, active jobs: 2 / active goroutines: 12
4:38PM --- | 41| 33| 39| 35| 44| 35| 42| 36|, active jobs: 2 / active goroutines: 12
4:38PM --- | 37| 35| 30| 36| 34| 33| 36| 36|, active jobs: 2 / active goroutines: 12
4:38PM WRN job 0
     Job|     Read| Write| Time|target
   Job 1| 4.7 Gbps| 0 bps| 8.00|get https://localhost:7333/10g
 Average| 4.7 Gbps| 0 bps| 8.00|


HTTP:
4:48PM WRN nspeed listening on http://127.0.0.1:7333 job=0
4:48PM --- |  4|  2|  1|  1|  4|  3|  7|  6|, active jobs: 2 / active goroutines: 6
4:48PM --- | 85| 25| 55| 38|  9|  1|  1| 16|, active jobs: 2 / active goroutines: 10
4:48PM --- | 94|  1|  7| 18|  2| 84|  0|  4|, active jobs: 2 / active goroutines: 10
4:48PM --- | 84| 37|  8| 24| 15| 23|  1|  1|, active jobs: 2 / active goroutines: 10
4:48PM --- | 13| 94| 32| 24| 28|  3|  0|  0|, active jobs: 2 / active goroutines: 10
4:48PM --- |  1|  2| 31| 27|100|  3|  0|  5|, active jobs: 2 / active goroutines: 10
4:48PM --- | 14| 36| 53|  3| 54|  2|  1| 33|, active jobs: 2 / active goroutines: 10
4:48PM --- | 12|  2|100|  0| 30| 24|  1|  7|, active jobs: 2 / active goroutines: 10
4:48PM WRN job 0
     Job|      Read| Write| Time|target
   Job 1| 41.5 Gbps| 0 bps| 7.71|get http://localhost:7333/40g
 Average| 41.5 Gbps| 0 bps| 7.71|


(Intel i7-8559U CPU @ 2.70GHz - Linux 5.4.0-72 - Ubuntu 20.04.2 LTS)

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
NSpeed: nouveau projet de mesure de débit
« Réponse #109 le: 18 mai 2021 à 19:06:09 »
Effectivement, pourtant TLS_AES_128_GCM_SHA256.

Voici ce que dit perf, il y a quand même du CPU consommé pour le TLS (et memmove, ensuite le findrunnable je ne sais pas si c'est normal) :
   9.24%  nspeed_linux_am  nspeed_linux_amd64  [.] crypto/aes.gcmAesEnc
   9.15%  nspeed_linux_am  nspeed_linux_amd64  [.] crypto/aes.gcmAesDec
   6.96%  nspeed_linux_am  nspeed_linux_amd64  [.] runtime.memmove
   5.92%  nspeed_linux_am  nspeed_linux_amd64  [.] runtime.findrunnable
   4.53%  nspeed_linux_am  nspeed_linux_amd64  [.] runtime.selectgo
   3.43%  nspeed_linux_am  nspeed_linux_amd64  [.] runtime.procyield
   2.33%  nspeed_linux_am  nspeed_linux_amd64  [.] runtime.lock2
   1.58%  nspeed_linux_am  nspeed_linux_amd64  [.] runtime.casgstatus
   1.42%  nspeed_linux_am  nspeed_linux_amd64  [.] runtime.unlock2
   1.34%  nspeed_linux_am  nspeed_linux_amd64  [.] runtime.mallocgc
AES-NI semble pourtant être utilisé.

findrunnable/selectgo/procyield : est-ce qu'il n'y aurait pas un peu trop de découpage de tâches (trop petites ?) entre threads ?
Les coeurs ne saturent pas, mais ça se répartit bien, entre N+1 threads, pour N coeurs logiques ?

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #110 le: 18 mai 2021 à 20:13:28 »
findrunnable/selectgo/procyield : est-ce qu'il n'y aurait pas un peu trop de découpage de tâches (trop petites ?) entre threads ?
Les coeurs ne saturent pas, mais ça se répartit bien, entre N+1 threads, pour N coeurs logiques ?

bonne piste! effectivement quand on réduit le nombre de cœurs a utiliser la perf augmente...

la variable d'env GOMAXPROCS permet de limiter le nombre de cœurs:
GOMAXPROCS=2 ./nspeed_linux_amd64 ...donne de meilleurs résultats que sans GOMAXPROCS

Je vais voir si on peut agir au niveau du code ou si y'a des caveats/workaround pour ce genre de chose.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #111 le: 21 mai 2021 à 14:24:50 »
apparemment le 'coupable' est ... HTTP/2 plus que le chiffrement

j'ai ajouté le forcage d'HTTP 1.1 et H2C (http/2 sans chiffrement) a nspeed et fait aussi quelque tests avec curl et un serveur nspeed et curl/nspeed avec un serveur nginx (fichiers de 1G,10G et 40GB sur un ssd M2, 'sendfile' activé)

HTTP/1.1 sans chiffrement
server -n 1 get -w 1  http://localhost:7333/10g
     Job|      Read| Write| Time|target
   Job 1| 41.4 Gbps| 0 bps| 1.93|get http://localhost:7333/10g
 Average| 41.4 Gbps| 0 bps| 1.93|

curl: 48 Gbps
curl avec nginx: 30 Gbps puis s'écroule a 0 ?!
nspeed avec nginx: 30 Gbps

HTTP/1.1 avec chiffrement
server -self -n 1 get -self  -w 1 -http11  https://localhost:7333/10g
     Job|      Read| Write| Time|target
   Job 0| 13.9 Gbps| 0 bps| 5.76|get https://localhost:7333/10g
 Average| 13.9 Gbps| 0 bps| 5.76|

curl: 12 Gbps
curl avec nginx: 9.6 Gbps
nspeed avec nginx: 9.3 Gbps

HTTP/2 avec chiffrement
server -self -n 1 get -w 1 -self  https://localhost:7333/10g
     Job|     Read| Write| Time|target
   Job 1| 4.6 Gbps| 0 bps| 8.00|get https://localhost:7333/10g
 Average| 4.6 Gbps| 0 bps| 8.00|

curl: 5.6 Gbps
curl avec nginx: 8 Gbps
nspeed avec nginx: 5.6 Gbps

H2C
server -h2c -n 1 get -w 1 -h2c  http://localhost:7333/10g
     Job|     Read| Write| Time|target
   Job 1| 7.2 Gbps| 0 bps| 8.00|get http://localhost:7333/10g
 Average| 7.2 Gbps| 0 bps| 8.00|

curl: 8.9 Gbps

Avec nginx c'est TLS1.3 / TLS_AES_256_GCM_SHA384 qui est utilisé que ce soit curl ou "nspeed get"
Avec "nspeed server" c'est TLS1.3 / TLS_AES_128_GCM_SHA256 qui est utilisé que ce soit curl ou "nspeed get"

Le chiffrement pénalise de x3 environ (40 a 13) donc mais HTTP/2 (sans chiffrement) bien plus environ x4 (40 a 7). Le mélange deux (HTTP/2 normal) explique donc les résultats (presque x10)

Je n'ai pas testé avec Apache mais j'ai testé avec Caddy, serveur écrit en Go et il fait moins bien que le serveur nspeed.

reste a voir pourquoi HTTP/2 fait moins bien que HTTP/1.1 pour du simple transfert de fichier et pourquoi nginx fait mieux que nspeed avec http/2 chiffré (peut-etre sendfile?).

La v0.8 la semaine prochaine, ajoutera ces options (forcé HTTP 1.1 et forcé H2C) ainsi qu'une nouvelle commande pour voir et changer les cyphers de chiffrement.

Kartman

  • Abonné Orange vdsl
  • *
  • Messages: 97
  • FTTLa 1000/60 sur Croix (59)
NSpeed: nouveau projet de mesure de débit
« Réponse #112 le: 22 mai 2021 à 12:23:02 »
Je viens de tester avec hyper et alpn h2 fixer sur openssl pour le HTTP/2 et nginx comme serveur.

nspeed 0.7
./nspeed_linux_amd64 get http://localhost/1G.iso
{"level":"debug","time":"2021-05-22T11:59:41+02:00","message":"use self TLS: false"}
Jobs:
  0 {Command: GET, URL: "http://localhost/1G.iso", IPversion: 0, Address: , Instance: 0, timeout: 8s}
     Job|      Read| Write| Time|target
   Job 0| 39.7 Gbps| 0 bps| 0.20|get http://localhost/1G.iso
 Average| 39.7 Gbps| 0 bps| 0.20|

GODEBUG=x509ignoreCN=0 ./nspeed_linux_amd64 -self get https://localhost/1G.iso
{"level":"debug","time":"2021-05-22T11:54:09+02:00","message":"use self TLS: true"}
Jobs:
  0 {Command: GET, URL: "https://localhost/1G.iso", IPversion: 0, Address: , Instance: 0, timeout: 8s}
     Job|     Read| Write| Time|target
   Job 0| 4.3 Gbps| 0 bps| 1.88|get https://localhost/1G.iso
 Average| 4.3 Gbps| 0 bps| 1.88|

GODEBUG=x509ignoreCN=0 ./nspeed_linux_amd64 -self get https://localhost/1G.iso get https://localhost/1G.iso
{"level":"debug","time":"2021-05-22T12:04:35+02:00","message":"use self TLS: true"}
{"level":"debug","time":"2021-05-22T12:04:35+02:00","message":"use self TLS: true"}
Jobs:
  0 {Command: GET, URL: "https://localhost/1G.iso", IPversion: 0, Address: , Instance: 0, timeout: 8s}
  1 {Command: GET, URL: "https://localhost/1G.iso", IPversion: 0, Address: , Instance: 0, timeout: 8s}
     Job|     Read| Write| Time|target
   Job 0| 3.4 Gbps| 0 bps| 2.35|get https://localhost/1G.iso
   Job 1| 3.4 Gbps| 0 bps| 2.36|get https://localhost/1G.iso
 Average| 6.8 Gbps| 0 bps| 2.36|


Les données sont en millisecondes et chaque test est exécuté 10 fois.
Les 2 derniers résultats sont basé sur l’exécution de 2 requêtes exécutées en parallèle.
Comme vous avez noté les résultats avec le http/2 est nettement moins bons, je trouve encore plus bizarre que le lancement en parallèle n’améliore rien (je pense à un problème avec mon code).
**************************
http1.1 min:180 max:252 avg:205.7~38.89159Gbps (10)
**************************
https min:886 max:1527 avg:1173.1~6.819538Gpbs (10)
**************************
https h2 min:1400 max:1579 avg:1481.9~5.398475Gbps (10)
**************************
2 https min:769 max:902 avg:826.4~19.361084Gbps (10)
**************************
2 https h2 min:2826 max:3133 avg:2973.7~5.380502Gbps (10)

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #113 le: 25 mai 2021 à 14:27:45 »
intéressant tout ca.

j'ai testé le serveur h2o censé être un 'rapide': https://github.com/h2o/h2o

j'obtient en HTTP/2 (cipher=TLS_AES_256_GCM_SHA384 crypto=TLS13)

serveur h2o:
  client nspeed 1 flux:  8.1 Gbps
  client curl 1 flux: 12 Gbps
  nspeed 4 flux:  19.8 Gbps

serveur nspeed:
  client nspeed 1 flux: 4,3 Gbps
  client curl 1 flux: 5,3 Gbps
  client nspeed 4 flux:  14 Gbps

et en forcant HTTP1.1:

serveur h2o:
  client nspeed 1 flux: 16 Gbps
  client curl 1 flux: 11.2 Gbps
  client nspeed 4 flux: 32 Gbps

serveur nspeed:
  client nspeed 1 flux: 13 Gbps
  client curl 1 flux: 12 Gbps
  client nspeed 4 flux: 35 Gbps


bon apres y'a peut-être des réglages spécifiques à faire dans nginx ou h2o pour avoir mieux et un test sur localhost n'est pas forcément représentatif d'une meilleur performance sur réseau réel. Il faudrait avoir un serveur 40Gbs avec nspeed, apache, nginx et h2o pour faire des comparaisons plus précises.

Mais y'a nettement moins de performance en HTTP/2 avec le code Go. Reste a savoir pourquoi.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #114 le: 25 mai 2021 à 15:11:39 »
v0.8 dispo: https://dl.nspeed.app/nspeed-client/v0.8/
nouveau répertoire https://dl.nspeed.app/nspeed-client/latest pour toujours avoir la dernière version directement

peu de changements, juste une version pour aider au benchmarking d'http/2
v0.8
general
  a few typos fixes
  added -h2c mode to client & server to allow HTTP/2 Cleartext (H2C)
client
  -http11 flag to force HTTP 1.1 when connecting to HTTP/2 server
cyphers
  new command cyphers to list supported cyphers with that server (will test only TLS 1.2 and 1.3)

la nouvelle commande permet de lister les cyphers tls 1.2 et 1.3 supporté pas un serveur web,par exemple:

./nspeed_linux_amd64 cyphers lafibre.info
Jobs:
  0 cyphers {Target: lafibre.info, delay: 0}
3:07PM lafibre.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 job=0
3:07PM lafibre.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 job=0
3:07PM lafibre.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 job=0
3:07PM | WARN  | job 0 ended
nothing to report

lafibre.info pas TLS 1.3 et pas de CHACHA20 ?!

./nspeed_linux_amd64 cyphers testdebit.info
Jobs:
  0 cyphers {Target: testdebit.info, delay: 0}
3:08PM testdebit.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 job=0
3:08PM testdebit.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 job=0
3:08PM testdebit.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 job=0
3:08PM testdebit.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 job=0
3:08PM testdebit.info:443 supports TLS 1.3 TLS_AES_128_GCM_SHA256 job=0
3:08PM testdebit.info:443 supports TLS 1.3 TLS_CHACHA20_POLY1305_SHA256 job=0
3:08PM testdebit.info:443 supports TLS 1.3 TLS_AES_256_GCM_SHA384 job=0
3:08PM | WARN  | job 0 ended
nothing to report

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #115 le: 26 mai 2021 à 16:45:27 »
petit début d'explication. en ajoutant "GODEBUG=http2debug=1" devant le serveur nspeed:

GODEBUG=http2debug=1 nspeed -verbose server -self -a ""
quand on fait un curl d'1GiB (curl -k -o /dev/null https://localhost:7333/1G), on voit (lignes filtrées):

2021/05/26 16:15:44 http2: server read frame SETTINGS len=18, settings: MAX_CONCURRENT_STREAMS=100, INITIAL_WINDOW_SIZE=1073741824, ENABLE_PUSH=0
2021/05/26 16:15:44 http2: server processing setting [MAX_CONCURRENT_STREAMS = 100]
2021/05/26 16:15:44 http2: server processing setting [INITIAL_WINDOW_SIZE = 1073741824]
2021/05/26 16:15:44 http2: server processing setting [ENABLE_PUSH = 0]
2021/05/26 16:15:44 http2: server read frame WINDOW_UPDATE len=4 (conn) incr=1073676289
2021/05/26 16:15:44 http2: server read frame HEADERS flags=END_STREAM|END_HEADERS stream=1 len=34
2021/05/26 16:15:44 http2: server read frame SETTINGS flags=ACK len=0
2021/05/26 16:15:45 http2: server read frame WINDOW_UPDATE len=4 (conn) incr=536870912
2021/05/26 16:15:45 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=536870912
2021/05/26 16:15:46 http2: server read frame WINDOW_UPDATE len=4 (conn) incr=536870912
2021/05/26 16:15:46 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=536870912
on a une INITIAL_WINDOW_SIZE a 1073741824 (1Go+) et curl envoie des WINDOW_UPDATE a 50% reçu (536870912 * 2 = 1073741824)
donc en gros tout les 500Mo recu curl envoi un WINDOW_UPDATE

avec NSpeed client: (nspeed get -self https://localhost:7333/1G)

on a

2021/05/26 16:22:28 http2: server read frame SETTINGS len=18, settings: ENABLE_PUSH=0, INITIAL_WINDOW_SIZE=4194304, MAX_HEADER_LIST_SIZE=10485760
2021/05/26 16:22:28 http2: server processing setting [ENABLE_PUSH = 0]
2021/05/26 16:22:28 http2: server processing setting [INITIAL_WINDOW_SIZE = 4194304]
2021/05/26 16:22:28 http2: server processing setting [MAX_HEADER_LIST_SIZE = 10485760]
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE len=4 (conn) incr=1073741824
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=49152
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=32768
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=32768
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=32768
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
..... 57300+ lignes comme ca
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=32768
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=32768
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384

on a une INITIAL_WINDOW_SIZE a  4194304 (4Mo) et tout les 16K reçu  (des fois plus), nspeed envoi un WINDOW_UPDATE au serveur...pas étonnant que la performance soit moindre, le serveur est martelé de WINDOW_UPDATE et ajuste son tampon pour rien (nspeed client envoi 57K+ WINDOW_UPDATE, curl en envoi 2).

a voir donc pourquoi le client Go http/2 fait cela et si on peut corrigé (a priori ce n'est pas lié a la facon dont nspeed traite les données recu, la taille du buffer de reception au niveau application ne change rien). J'aurais voulu éviter de me plonger dans les détails d'HTTP/2 (!) mais je n'ai pas trop le choix on dirait.
« Modifié: 26 mai 2021 à 22:02:38 par kgersen »

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
NSpeed: nouveau projet de mesure de débit
« Réponse #116 le: 26 mai 2021 à 21:34:32 »
La taille par défaut dans la norme est de seulement 65535.

Tu as testé avec un curl qui n'est pas à jour à priori.
Avant curl 7.52, c'était la taille par défaut (64Ko).
En 7.52 ils sont passés à 1Go (https://github.com/curl/curl/issues/1102).
En 7.69, ils ont réduit à 32Mo (https://github.com/curl/curl/issues/4939).

Si la window est assez large, les WINDOW_UPDATE reçus par le serveur ne devraient pas faire grand chose, à part consommer un peu de CPU.
Il n'y a que si le serveur avait déjà rempli la window du client, et a donc dû s'arrêter, que reprendre pour juste 16Ko/32Ko n'est pas très optimal, et qu'il serait bénéfique que le client attende soit une durée minimale, soit une taille minimale avant d'envoyer un WINDOW_UPDATE qui débloque le serveur.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #117 le: 26 mai 2021 à 21:55:17 »
La taille par défaut dans la norme est de seulement 65535.

Tu as testé avec un curl qui n'est pas à jour à priori.
Avant curl 7.52, c'était la taille par défaut (64Ko).
En 7.52 ils sont passés à 1Go (https://github.com/curl/curl/issues/1102).
En 7.69, ils ont réduit à 32Mo (https://github.com/curl/curl/issues/4939).


c'est le curl de base d'un Ubuntu 20.04 TLS (je voulais tester avec un curl d'une distro LTS populaire justement).

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:        20.04
Codename:       focal

curl -V
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets

c'est bien 7.68 du "8 Jan 2020" , https://launchpad.net/ubuntu/focal/+source/curl (et comme d'hab Ubuntu a 1 an de retard sur des paquets importants...)

Si la window est assez large, les WINDOW_UPDATE reçus par le serveur ne devraient pas faire grand chose, à part consommer un peu de CPU.
Il n'y a que si le serveur avait déjà rempli la window du client, et a donc dû s'arrêter, que reprendre pour juste 16Ko/32Ko n'est pas très optimal, et qu'il serait bénéfique que le client attende soit une durée minimale, soit une taille minimale avant d'envoyer un WINDOW_UPDATE qui débloque le serveur.

oui y'a un truc qui cloche quand meme.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #118 le: 21 juin 2021 à 11:54:31 »
Le refactoring du code avance. l'api est commencé. l'ui aussi.

Un projet similaire est apparu: https://github.com/six-ddc/plow mais mais que 'client'. pas serveur.
c'est plus orienté latence & requetes/secondes que débit mais il y a peut-être des choses intéressantes a reprendre notamment l'UI web des courbes qui est exactement ce que je voulais faire (mais dans le cas de nspeed plus en 'replay' a la fin qu'en temps réel qui consomme des ressources cpu pour peu d'avantage).
C'est basé sur une autre lib http donc pas de http/2 ou autre.





kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #119 le: 12 août 2021 à 12:25:52 »
v0.9 dispo: https://dl.nspeed.app/nspeed-client/v0.9/
ou https://dl.nspeed.app/nspeed-client/latest pour toujours avoir la dernière version directement

gros changements internes (refactoring) pour l'api et la préparation de l'interface web: https://github.com/nspeed-app/nspeed/blob/main/CHANGELOG.md ainsi que le moteur interne d’ordonnancement (scheduling des threads).

La grosse nouveauté visible est la command 'api' permettant a nspeed d'écouter en http pour recevoir des commandes (sorte d'API REST mais qu'avec un GET).
Ceci fonctionne en local ou distance. pour le moment nspeed n'est pas encore client de l'api donc utiliser curl par exemple ou un navigateur.

exemple en local:
nspeed api
puis ouvrez http://localhost:7333/api/v1/run?args=get%20https://scaleway.testdebit.info/1G/1G.iso sur la meme machine
(par défaut l'api n'ecoute que sur localhost)

ou en CLI:

curl http://localhost:7333/api/v1/run?args=get%20https://scaleway.testdebit.info/1G/1G.iso
(il faut remplacer les espaces par %20)

pour ouvrir l'api sur le LAN ou internet utiliser l'option -a comme avec 'server'.

nspeed api -a ""va ouvrir l'api sur tout les adresses de la machine (attention a pas laisser cela a poil sur le Net)

Cela permet donc de lancer nspeed a distance depuis une autre machine. pour le moment avec curl ou un navigateur mais plus tard nspeed utilisera aussi l'api comme "agent" (pour le moment on peut quand meme utiliser l'api depuis nspeed puisque c'est du 'get http' aussi mais on n'a pas le retour du resultat donc ca ne sert qu'a synchroniser des nspeed sur plusieurs machines en meme temps).

on peut partager l'api et le server sur le meme port:
nspeed server -apiou avoir chacun son port/interface:
nspeed server -a "" api -a tailscale0 -p 8888 -4le server écoute sur toutes interfaces/addresse port nspeed par défaut (7333), l'api n'est que sur l'interface tailscale0 port 8888 et en IPv4

Les étapes suivantes:
-traceroute (on pourra donc faire un traceroute depuis nspeed ou vers soi depuis un serveur nspeed via l'api)
-ping/latence (idem)
- metrics (format structurés des résultats pour : base de donnée, graphiques, prometheus, etc probablement au format: https://openmetrics.io/ )
- interface web
- info hardware/routage (crosstalk  & erreurs carte réseau, bus pci, etc)
- api box (<<bbox uniquement pour le moment>>)

La mise en oeuvre de l' interface web est reculé apes les metrics car ce ne sert a pas a grand chose d'afficher du texte dans un navigateur autant être en ligne de commande. Je préfère  avoir des métrics bien structurés et les présenter sous forme de tableaux ou courbes par exemple.