Ouais enfin pour faire du trafic >10G, il vaut mieux éviter de passer par un vieux proxy tout pourri

Je connais peu Squid et je ne le recommanderai pas ici mais des "vieux" proxy comme HAProxy ca tient la route.

Apres son Apache il peut cracher 5000 MB/s (40 Gps) ? ou même son disque aussi vu que c'est un vrai fichier qui est servi ? (a moins qu'il passe par un ramfs ou autre).

Faudrait déja qu'il bench son serveur pour voir ou y'a des limites. Je ne pense pas qu'une seule session tcp puisse atteindre 40 Gbps de toute facon.

Certes mais si tu veux proxyfier de l'iperf par exemple, pas dit que ça tienne le débit.

oui un proxy va surement pas suivre ou alors en bouffant un max de cpu (encore que ca serait intéressant de bench un haproxy devant iperf).

pour iperf on avais un début de solution en 2016 mais Vivien n'a pas poursuivi (enfin je sais plus pourquoi y'a pas eu de suite): https://lafibre.info/iperf/abus-sur-serveur-iperf3-public/

Il me semble pas que ça fasse ce que Vivien veut, c'est plutôt pour des gens qui font du mutu et qui veulent pouvoir limiter le trafic généré par certains vhost.

Il y'a 3 modes: "per-user, per-virtualhost and per-destination"

CBandLimit c'est par virtualhost
CBandUserLimit c'est par user.

Ce que je ne sais pas c'est si la notion de 'user' peut se ramener a une IPv4/prefix IPv6 ou s'il faut créer des users (au sens "authentification" donc avec un mod_auth...) avant.

De ce que j'ai lu la notion d'utilisateur ici n'est pas celle qui intéresse Vivien, ce sont des utilisateurs spécifiques au niveau de "mod_cband" qui permettent de regrouper plusieurs vhost.

ah ok je n'ai pas creusé plus que ca.

Je pense que l'on va faire sans au démarrage.

Je dois être vieux, de la vieille école mais moi un speedtest ca doit pas aller titiller les process style AV comme tu veux les tester...

Tu peux proposer les 2: du urandom incompressible et ton ISO rempli de libreoffice portable je vois ton idée mais laisser le choix c'est mieux...

Il y aura même 3 types de fichiers, je finalise la configuration.
- 1G.zip : A partir de 1Mo, c'est un vrai fichier Zip d'applications Windows open source. Entre 500 Ko et 50 octets, c'est une image (jpeg / png / gif selon les tailles).
- 1G-rand.zip : Données aléatoires (non compressible)
- 1G-zero.zip : Fichier rempli d'octets à la valeur zéro en hexadécimal (très fortement compressible)

Taille et nom des fichiers dans le ramdisque :
10000000000 10G.zip
 1000000000 1G-rand.zip
 1000000000 1G-zero.zip
 1000000000 1G.zip
  262144000 250Mi-rand.zip
  100000000 100M-rand.zip
  100000000 100M-zero.zip
  100000000 100M.zip
   50000000 50M-rand.zip
   50000000 50M-zero.zip
   50000000 50M.zip
   10000000 10M-rand.zip
   10000000 10M-zero.zip
   10000000 10M.zip
    5000000 5M-rand.zip
    5000000 5M-zero.zip
    5000000 5M.zip
    1000000 1M-rand.zip
    1000000 1M-zero.zip
    1000000 1M.zip
     500000 500k.jpg
     500000 500k-rand.jpg
     500000 500k-zero.jpg
     100000 100k.jpg
     100000 100k-rand.jpg
     100000 100k-zero.jpg
      50000 50k.jpg
      50000 50k-rand.jpg
      50000 50k-zero.jpg
      10000 10k.jpg
      10000 10k-rand.jpg
      10000 10k-zero.jpg
       5000 5k.jpg
       5000 5k-rand.jpg
       5000 5k-zero.jpg
       1000 1k.jpg
       1000 1k-rand.jpg
       1000 1k-zero.jpg
        500 500.png
        500 500-rand.png
        500 500-zero.png
        100 100.png
        100 100-rand.png
        100 100-zero.png
         50 50.gif
         50 50-rand.gif
         50 50-zero.gif
         10 10.exe
         10 10-rand.exe
         10 10-zero.exe
          5 5.exe
          5 5-rand.exe
          5 5-zero.exe
          1 1.exe
          1 1-rand.exe
          1 1-zero.exe
          0 0.exe
          0 0-rand.exe
          0 0-zero.exe

Ces fichiers seront disponibles dans pleins d'extensions, via des liens réalisé vers le fichier d'origine.

Tous ces fichiers sont en ramdisque (rempli automatiquement au démarrage du serveur), permettant un débit de 40 Gb/s.

J'utilise une archive au format LZ4 pour remplir le ramdisque (il y l'ensemble des fichiers dans l'archive LZ4). C'est un format vraiment intéressant, car en décompression il n'utilise presque pas de CPU et il permet donc de gagner en temps CPU et disque.

Comparaison du temps CPU pour un fichier test :
- gzip compression: 8.1secondes - décompression: 3.5s
- bzip compression: 258.3secondes - décompression: 3.4s
- lzma compression: 31.7secondes - décompression: 6.7s
- lzma -e compression: 4m37secondes - décompression: 5.9s
- xz compression: 32.2secondes - décompression: 7.2s
- xz -e compression: 4m40secondes - décompression: 6.5s
- lz4 compression: 1.3secondes - décompression: 0.4s
- lzop compression: 1.6secondes - décompression: 1.5s

Je ne suis pas convaincu d'un serveur de mires bâti sur Apache2   

Au moins Nginx ou un truc plus moderne mais Apache2 

Cela dit , il faudrait bencher Apache vs NGinx vs Caddy (vs NSpeed quand stable) pour confirmer tout ca. L'avantage de NSpeed est que les 'fichiers' sont dynamiquement générés en terme de taille et de type ( j'ai même prévu plus tard de pouvoir choisir les 512 premiers octets pour les détecteurs de contenu et autre anti-virus) donc y'a aucune charge cpu & appel système pour lire des fichiers.

Sinon tout les serveurs web peuvent même mettre en cache eux même des fichiers statiques et les "serviront" plus rapidement que via un ramdisk (car ils ne feront plus de 'read' système (syscall) pour lire les données). y'a  mod_file_cache par exemple pour Apache il me semble (mais je n'ai jamais benché cela).

Apres si le cpu est surdimensionné pour 40 Gbps ca ne fera pas grande différence a part la température C'est toujours le même combat entre logiciel et matériel: si t'as pas le code optimisé ou qui va bien tu mets du gros matos hardware pour compenser...c'est souvent moins cher, plus simple et rapide à mettre en œuvre d'ailleurs que de développer du code.