La Fibre

Télécom => Réseau => testdebit Comment tester son débit ? => Discussion démarrée par: vivien le 28 avril 2017 à 17:21:47

Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 28 avril 2017 à 17:21:47
Réaliser un test de débit descendant ou montant avec CURL sous Linux

Également disponible : Tutoriel CURL pour Windows (https://lafibre.info/tester-son-debit/curl-upload/) et Tutoriel CURL pour MacOS (https://lafibre.info/tester-son-debit/curl-mac/)

Vous connaissez WGET ? ( wget -O /dev/null http://bouygues.testdebit.info/1G.iso )
CURL offre plus d'options.

Installer CURL sous Linux (Ubuntu, Debian et dérivés)

- Ouvrez un terminal (Raccourci clavier : "Ctrl" + "Alt" + "T")
- Exécutez sudo apt install curl



Test de débit descendant (download) sur une connexion TCP sous Linux :

Le débit moyen est affiché dans la colonne Average Dload. C'est un débit en Mo/s et non en Mb/s. C'est un débit utile, les encapsulations ne sont pas comptées.

IPv4 uniquement :
- http, sur une durée de 8 secondes : curl --max-time 8 -4 -o /dev/null http://bouygues.testdebit.info/10G.iso
- https, sur une durée de 8 secondes : curl --max-time 8 -4 -o /dev/null https://bouygues.testdebit.info/10G.iso
- http, taille fixe de 100Mo : curl -4 -o /dev/null http://bouygues.testdebit.info/100M.iso
- https, taille fixe de 100Mo : curl -4 -o /dev/null https://bouygues.testdebit.info/100M.iso
- http, taille fixe de 1Go : curl -4 -o /dev/null http://bouygues.testdebit.info/1G.iso
- https, taille fixe de 1Go : curl -4 -o /dev/null https://bouygues.testdebit.info/1G.iso


IPv6 uniquement :
- http, sur une durée de 8 secondes : curl --max-time 8 -6 -o /dev/null http://bouygues.testdebit.info/10G.iso
- https, sur une durée de 8 secondes : curl --max-time 8 -6 -o /dev/null https://bouygues.testdebit.info/10G.iso
- http, taille fixe de 100Mo : curl -6 -o /dev/null http://bouygues.testdebit.info/100M.iso
- https, taille fixe de 100Mo : curl -6 -o /dev/null https://bouygues.testdebit.info/100M.iso
- http, taille fixe de 1Go : curl -6 -o /dev/null http://bouygues.testdebit.info/1G.iso
- https, taille fixe de 1Go : curl -6 -o /dev/null https://bouygues.testdebit.info/1G.iso
Titre: Linux: Réaliser un test de débit montant avec CURL
Posté par: vivien le 28 avril 2017 à 17:24:18
Préparatif pour une test de débit montant (upload) : télécharger un ficher de grande taille appelé /tmp/temp.iso

- Exemple avec un fichier de 10 Mo : curl -o /tmp/temp.iso https://bouygues.testdebit.info/10M.iso
- Exemple avec un fichier de 100 Mo : curl -o /tmp/temp.iso https://bouygues.testdebit.info/100M.iso
- Exemple avec un fichier de 1 Go : curl -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso
- Exemple avec un fichier de 10 Go : curl -o /tmp/temp.iso https://bouygues.testdebit.info/10G.iso



Test de débit montant (upload) sur une connexion TCP sous Linux :

Le débit moyen est affiché dans la colonne Average Upload. C'est un débit en Mo/s et non en Mb/s. C'est un débit utile, les encapsulations ne sont pas comptées.
Selon le paramétrage de HTTP/2 (comportement par défaut avec https), le débit peut être limité en fonction des paramétrages HTTP/2 du serveur.

IPv4 uniquement :
http HTTP/1.1, sur une durée de 60 secondes : curl --max-time 60 -4 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/1.1, sur une durée de 60 secondes : curl --max-time 60 -4 -w %{size_upload} --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/
http HTTP/1.1, sans limite de durée : curl -4 -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/1.1, sans limite de durée : curl -4 --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/

http HTTP/2, sur une durée de 60 secondes : curl --max-time 60 -4 -w %{size_upload} --http2-prior-knowledge -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/2, sur une durée de 60 secondes : curl --max-time 60 -4 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/
http HTTP/2, sans limite de durée : curl -4 --http2-prior-knowledge -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/2, sans limite de durée : curl -4 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/


IPv6 uniquement :
http HTTP/1.1, sur une durée de 60 secondes : curl --max-time 60 -6 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/1.1, sur une durée de 60 secondes : curl --max-time 60 -6 -w %{size_upload} --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/
http HTTP/1.1, sans limite de durée : curl -6 -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/1.1, sans limite de durée : curl -6 --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/

http HTTP/2, sur une durée de 60 secondes : curl --max-time 60 -6 -w %{size_upload} --http2-prior-knowledge -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/2, sur une durée de 60 secondes : curl --max-time 60 -6 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/
http HTTP/2, sans limite de durée : curl -6 --http2-prior-knowledge -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/
https HTTP/2, sans limite de durée : curl -6 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/

Attention : le débit est calculé coté émetteur : tout paquet émis et non acquitté est compté dans les données "size_upload"
Si une box a un petit débit et de gros buffers, il est possible d'avoir une différence très importante, les données sont émises, mais elles ne sont pas reçues, car elles sont en transit dans le buffer de la box.
Il est donc indispensable d'avoir un test de longue durée (par exemple 60 secondes) en upload. En download 8 secondes suffisent par cotre, vu que le débit est calculé coté récepteur.
Titre: CURL Linux
Posté par: alain_p le 28 avril 2017 à 18:32:35
Toujours clair et pédagogique Vivien ! Par rapport à wget, l'avantage est de pouvoir tester l'upload avec curl ? Ou c'est simplement une alternative ?
Titre: CURL Linux
Posté par: vivien le 28 avril 2017 à 21:22:25
Curl permet de tester l'upload, wget ne le permet pas.

Curl permet de faire un téléchargement sur une durée, wget ne le permet pas.

Curl permet aussi de récupérer de nombreux indicateurs, quand il est scripté.

J'ai fait rapidement ce sujet, car on me pose régulièrement la question de comment tester l'upload sous Windows.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: willemijns le 24 août 2019 à 23:06:33
Hello, ftp://1.testdebit.info/ est HS ?
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 24 août 2019 à 23:17:29
Cela fait des années que le protocole FTP n'est plus proposé.

C'est un protocole obsolète et non représentatif d'un débit obtenu avec les autres protocoles.

Sur le port 21, c'est le protocole https qui écoute aujourd'hui sur mes serveurs.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: K-L le 25 août 2019 à 02:41:38
C'est un protocole obsolète et non représentatif d'un débit obtenu avec les autres protocoles.

Dans quels domaines ?
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: willemijns le 25 août 2019 à 10:06:14
J'avoue que toute la réponse de vivien m'a laissé coi... d'ou ma non réponse sur le champ en l'ayant lu hier soir.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 25 août 2019 à 10:07:30
FTP est un protocole qui date de 1971.

Il a de gros défauts :
- L'adresse IP est transportée dans le contenu des paquets (niveau application), ce qui entraîne des incompatibilités avec la translation d'adresse (NAT / CGNAT / ...) ou du code complexe pour modifier à la vollée le contenu des paquets.
- Il entraine des risques de sécurités type déni de service importants, un pirate peut demander un transfert entre deux serveurs sans faire passer le flxu par son serveur, c'est prévu par le protocole.
- Il ne permet pas d'être sur que le contenu n'a pas été modifié. N'importe qui sur le chemin peut lire et modifier les données, car tout est en clair sans aucun dispositif permettant d'assurer l'intégrité des données
- La complexité du protocole augmente le risque de failles logiciel sur le serveur, avec risque de modification des fichiers du serveur, saturation de l'espace disque ou exécution de code arbitraire
- La maintenance de plusieurs logiciels de serveurs FTP est faible et donc il y a plus de risque de sécurité, vs Apache.
- Un test de débit FTP n'est pas représentatif de ce que l'on aura avec un autre protocole, Il est donc peu pertinent.

FTP a peu d'avantages à part être supporté sur des machines bien anciennes. Si on cherche à faire des transfert de vieux système d'exploitation, cela peut être intéressant.

Bref, pour moi il faut oublier FTP et utiliser d'autre protocoles, comme par exemple SFTP (transfert sur SSH) ou HTTPS, ce dernier ayant l'avantage de la représentativité (de plus en plus tout passe sur https)
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: willemijns le 25 août 2019 à 10:46:27
> FTP est un protocole qui date de 1971.

et ?

> - L'adresse IP est transportée dans le contenu des paquets (niveau application), ce qui entraîne des incompatibilités avec la translation d'adresse (NAT / CGNAT / ...) ou du code complexe pour modifier à la vollée le contenu des paquets.

c'est possible mais c'est pas un élèment déterminant pour notre cas soit du test UP et DL simple.

> - Il entraine des risques de sécurités type déni de service importants, un pirate peut demander un transfert entre deux serveurs sans faire passer le flux par son serveur, c'est prévu par le protocole.

exact... on peut trouver du possible bridage à faire pour limiter tout cela....

> - Il ne permet pas d'être sur que le contenu n'a pas été modifié. N'importe qui sur le chemin peut lire et modifier les données, car tout est en clair sans aucun dispositif permettant d'assurer l'intégrité des données

comme une page web en HTTP non HTTPS ^^

> - La complexité du protocole augmente le risque de failles logiciel sur le serveur, avec risque de modification des fichiers du serveur, saturation de l'espace disque ou exécution de code arbitraire

réponse valable mais on peut répondre valablement aussi avec "c'est partout pareil" ....

> - La maintenance de plusieurs logiciels de serveurs FTP est faible et donc il y a plus de risque de sécurité, vs Apache.

le HTTP ou ses comperes de streaming/netflix c'est mini 50% des trames TCP...

> - Un test de débit FTP n'est pas représentatif de ce que l'on aura avec un autre protocole, Il est donc peu pertinent.

FTP, HTTP, SFTP, iperf, rsync...  bah comme partout il y a différents moyens de...

> FTP a peu d'avantages à part être supporté sur des machines bien anciennes.

oui un PC de 1985 par exemple ^^ j'aurais préféré lire "le HTTP permet de faire la majorité des usages du FTP
et 99% du trafic qui aurait du se faire en FTP est fesable en HTTP"

FREE a abandonné ftp://test-debit.free.fr surement pour cette raison, je te l'accorde....
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: K-L le 25 août 2019 à 17:11:12
Obsolète pour le sujet qui nous intéresse ici-même, d'accord.

Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 25 août 2019 à 18:14:21
le HTTP ou ses comperes de streaming/netflix c'est mini 50% des trames TCP...
Tu pense que FTP utilise moins d'octets que HTTP

Il me semble que non :

Debian ne va plus proposer de FTP à partir du 1er novembre 2017 : https://www.debian.org/News/2017/20170425.fr.html

Après de nombreuses années au service des besoins des utilisateurs et une utilisation encore plus décroissante en faveur de meilleures options, tous les services FTP debian.org destinés au public seront fermés le 1er novembre 2017.

Cette décision est motivée par les considérations suivantes :
- les serveurs FTP ne prennent pas en charge la mise en cache et l'accélération ;
- l'implèmentation de la plupart des logiciels a stagné et ceux-ci sont difficiles à utiliser et à configurer ;
- l'utilisation des serveurs FTP est plutôt faible puisque notre propre installateur n'offre pas depuis dix ans FTP comme moyen d'accès aux miroirs ;
- le protocole est peu efficace et demande l'ajout de bidouillages compliqués pour les pare-feu et les démons de répartition de charge.

> - L'adresse IP est transportée dans le contenu des paquets (niveau application), ce qui entraîne des incompatibilités avec la translation d'adresse (NAT / CGNAT / ...) ou du code complexe pour modifier à la vollée le contenu des paquets.

c'est possible mais c'est pas un élèment déterminant pour notre cas soit du test UP et DL simple.

Il faut modifier l'IP privée en IP publique dans les paquets de commande FTP, en quoi c'est un élèment intéressant ou déterminant ?

> - Il ne permet pas d'être sur que le contenu n'a pas été modifié. N'importe qui sur le chemin peut lire et modifier les données, car tout est en clair sans aucun dispositif permettant d'assurer l'intégrité des données

comme une page web en HTTP non HTTPS ^^
Tout bascule en https, même pour configurer ta box qui est chez toi https est en train de s'imposer.

Tous les tests de débit ont soit terminés leur migration en https (SpeedTest Ookle, nPerf, test UFC Que choisir) ou sont en train de la terminer (QoSi / 5G Mark, IPv6 test)
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: willemijns le 25 août 2019 à 18:17:23
Tu pense que FTP utilise moins d'octets que HTTP

non je disais que HTTP et les streams c'etait au minimum 50% des trames TCP ou plus génériquement c'est la majoritédes usages sur Internet. désolé ma phrase était pas clair je le conçois.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: willemijns le 25 août 2019 à 18:28:29
- les serveurs FTP ne prennent pas en charge la mise en cache et l'accélération ;
- l'implèmentation de la plupart des logiciels a stagné et ceux-ci sont difficiles à utiliser et à configurer ;
- l'utilisation des serveurs FTP est plutôt faible puisque notre propre installateur n'offre pas depuis dix ans FTP comme moyen d'accès aux miroirs ;
- le protocole est peu efficace et demande l'ajout de bidouillages compliqués pour les pare-feu et les démons de répartition de charge.[/color]

tout ce beau texte confirme bel et bien que le FTP pour la lecture/reception defichiers n'est pas éfficace mais comme je vais le confirmer qq lignes plus bas pour l'envoi c'est quand même mieux... de ne pas trop changer les habitudes de devs ;)

Pour les devs DEBIAN:
Les services des développeurs Debian ne seront pas affectés. Il s'agit des files d'attente d'envoi pour à la fois l'archive principale « main » et l'archive de sécurité :

on peut aussi rajouter que les filehosteurs comme dl.free.fr uptobox et autres 1 fichier.com apprécient particulierement le FTP................................................
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: willemijns le 25 août 2019 à 18:41:47
argh ! tu as modifié 1 ou 2 fois ton méssage ? j'avais point vu tout cela...

> Il faut modifier l'IP privée en IP publique dans les paquets de commande FTP, en quoi c'est un élèment intéressant ou déterminant ?

car c'est pas des données sensibles pour un test UP et DL, on envoye ou recoit souvent des ISO ou des fichiers de test randomisés...
 
> Tout bascule en https, même pour configurer ta box qui est chez toi https est en train de s'imposer.

oui... le HTTP(S) upload est bien suffisant pour les envois simples.....



Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 26 août 2019 à 11:59:18
> Il faut modifier l'IP privée en IP publique dans les paquets de commande FTP, en quoi c'est un élèment intéressant ou déterminant ?

car c'est pas des données sensibles pour un test UP et DL, on envoye ou recoit souvent des ISO ou des fichiers de test randomisés...

Oui, mais cela entraîne du code complexe dans tous les NAT, cela serait bien de pouvoir s'en passer dans quelques années.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 26 août 2019 à 12:02:59
Oui, mais cela entraîne du code complexe dans tous les NAT, cela serait bien de pouvoir s'en passer dans quelques années.

Donc garder FTP c'est encore une raison de pousser IPv6  ;D
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 26 août 2019 à 12:07:54
Je ne suis pas sur que FTP ne va pas supporter les mécanismes de translation DNS46/NAT46.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 26 août 2019 à 13:27:59
Je ne suis pas sur que FTP ne va pas supporter les mécanismes de translation DNS46/NAT46.

l'idée est juste de laisser un serveur FTP en 'IPv6 only' en oubliant complètement IPv4 & les mécanismes de transitions.
Titre: Linux: Réaliser un test de débit montant avec CURL
Posté par: sounours le 29 juillet 2021 à 11:03:27
Préparatif pour une test de débit montant (upload) : télécharger un ficher de grande taille appelé /tmp/temp.iso

- Exemple avec un fichier de 10 Mo : curl -o /tmp/temp.iso https://bouygues.testdebit.info/10M.iso
- Exemple avec un fichier de 100 Mo : curl -o /tmp/temp.iso https://bouygues.testdebit.info/100M.iso
- Exemple avec un fichier de 1 Go : curl -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso
- Exemple avec un fichier de 10 Go : curl -o /tmp/temp.iso https://bouygues.testdebit.info/10G.iso



Test de débit montant (upload) sur une connexion TCP sous Linux :

Le débit moyen est affiché dans la colonne Average Upload. C'est un débit en Mo/s et non en Mb/s. C'est un débit utile, les encapsulations ne sont pas comptées.

IPv4 uniquement :
http, sur une durée de 60 secondes : curl --max-time 60 -4 -w %{size_upload} -o /dev/null -F "filecontent=@/tmp/temp.iso" http://bouygues.testdebit.info
https, sur une durée de 60 secondes : curl --max-time 60 -4 -w %{size_upload} -o /dev/null -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info
http, sans limite de durée : curl -4 -o /dev/null -F "filecontent=@/tmp/temp.iso" http://bouygues.testdebit.info
https, sans limite de durée : curl -4 -o /dev/null -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info

IPv6 uniquement :
http, sur une durée de 60 secondes : curl --max-time 8 -6 -w %{size_upload} -o /dev/null -F "filecontent=@/tmp/temp.iso" http://bouygues.testdebit.info
https, sur une durée de 60 secondes : curl --max-time 8 -6 -w %{size_upload} -o /dev/null -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info
http, sans limite de durée : curl -6 -o /dev/null -F "filecontent=@/tmp/temp.iso" http://bouygues.testdebit.info
https, sans limite de durée : curl -6 -o /dev/null -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info

Attention : le débit est calculé coté èmetteur : tout paquet émis et non acquitté est compté dans les données "size_upload"
Si une box a un petit débit et de gros buffers, il est possible d'avoir une différence très importante, les données sont émises mais pas reçues car elles sont en transit dans le buffer de la box.
Il est donc indispensable d'avoir un test de longue durée (par exemple 60 secondes) en upload. En download 8 secodnes suffisent par cotre, vu que le débit est calculé coté récepteur.


Merci, t'es un chef !

Malgré l'âge des liens, ça marche toujours aussi bien !
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 18 novembre 2022 à 12:27:21
@vivien

sais-tu pourquoi l'upload ne fonctionne pas en http/2 sur ces serveurs ?

on obtient:

curl: (92) Stream error in the HTTP/2 framing layer

peux-tu poster ta config apache ?
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 18 novembre 2022 à 13:08:53
Accepter un fichier uploadé alors que le serveur n'a rien demandé pourrait aussi être considérée comme une anomalie (corrigée avec HTTP/2).

La configuration des serveurs est entièrement publique et est détaillé dans une section du forum : https://lafibre.info/ubuntu/

Je pense que le sujet qui va t'intéresser est Base: Installation et sécurisation d'Apache2 (https://lafibre.info/ubuntu/apache2/).

Si tu trouves comment faire fonctionner l'upoad avec HTTP/2, je ferais les modifications.
Si tu as besoin que je donne le contenu de fichier de configuration, indique-moi lesquels.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 18 novembre 2022 à 14:38:11
Si tu as besoin que je donne le contenu de fichier de configuration, indique-moi lesquels.

Je veux bien la conf apache2 (le .conf) du endpoint qui accepte les POST.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 18 novembre 2022 à 14:56:33
C'est ça ?
<VirtualHost *:443>
ServerName "bouygues.testdebit.info"
ServerAlias "ipv4.bouygues.testdebit.info"
ServerAlias "ipv6.bouygues.testdebit.info"

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/bouygues.testdebit.info/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/bouygues.testdebit.info/privkey.pem

DocumentRoot "/home/net-test/tmpfs"
<Directory "/home/net-test/tmpfs">
DirectoryIndex index.html
Options Indexes FollowSymLinks
IndexOptions +SuppressDescription
AllowOverride None
Require all granted
</Directory>

Alias "/web" "/home/net-test/web"
<Directory "/home/net-test/web">
Options None
AllowOverride None
Require all granted
</Directory>

Alias "/ul" "/home/net-test/ul"
<Directory "/home/net-test/ul">
Options None
AllowOverride None
Require all granted
</Directory>

Alias "/videos" "/home/net-test/videos"
<Directory "/home/net-test/videos">
Options None
AllowOverride None
Require all granted
</Directory>

ErrorLog "${APACHE_LOG_DIR}/net-test-error.log"
CustomLog "${APACHE_LOG_DIR}/net-test-443.log" combiport
</VirtualHost>

Le dossier "/home/net-test/ul" contient un fichier upload.php utilisé par certains outils (mais pas par Curl) :
<?php
$datas = file_get_contents('php://input');
$resultArray["status"] = "FICHIER RECU";

// retour vers le device
echo json_encode($resultArray);



//----------------------------- fonctions ---------------------------------------

function checkError($_val)
{
global $resultArray,$bd;

if (gettype($_val)=='string' && substr($_val,0,6)==substr(CONNEXION_ERROR,0,6))
{
$resultArray["status"] = $_val;
logToFile("error_log.txt",$_val);
echo json_encode($resultArray);
$bd->fermerConnexionBDD();
die();
}
}


function logToFile($filename,$msg)
{
      $fd=fopen($filename,"a");
      $str="[".date("Y/m/d h:i:s")."]".$msg;
      fwrite($fd,$str."\n");
      fclose($fd);
}

?>
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 18 novembre 2022 à 15:15:22
donc tu n'as pas de endpoint/traitement particulier pour les upload sur '/' comme indiqué en 1ere page:

curl -4 --http1.1 -o /dev/null -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info
ceci fait un POST sur '/' avec le contenu dans le POST. C'est cela qui ne marche pas en HTTP/2.

Je vais monter un apache2 pour faire des tests.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 18 novembre 2022 à 17:33:53
Rien de particulier, tu peux tester sur pleins de serveurs Apache sur Internet, uploader des fichiers vers le serveur ne pose aucun problème.

Très rapidement le serveur te répond que ta requête. Je viens de tester l'upload sur le site de l'Arcep fonctionne bien comme presque tous les serveurs Apache.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 19 novembre 2022 à 17:09:07
Rien de particulier, tu peux tester sur pleins de serveurs Apache sur Internet, uploader des fichiers vers le serveur ne pose aucun problème.

Très rapidement le serveur te répond que ta requête. Je viens de tester l'upload sur le site de l'Arcep fonctionne bien comme presque tous les serveurs Apache.

On peux envoyer 1G sur le site de l'arcep mais c'est un Varnish devant :

curl -I https://www.arcep.fr/
HTTP/2 200
date: Sat, 19 Nov 2022 15:49:38 GMT
server: Unknown
accept-ranges: bytes
age: 95
content-language: fr
content-length: 74537
content-security-policy: frame-ancestors 'self' https://www.arcep.fr https://en.arcep.fr;
content-type: text/html; charset=utf-8
vary: Accept-Encoding
via: 1.1 varnish (Varnish/6.0)
x-cache: HIT
x-cacheable: YES
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-ua-compatible: IE=edge
x-varnish: 7941207 7068477
x-varnish-host: 4ddae90f67da
x-xss-protection: 1; mode=block
strict-transport-security: max-age=63072000; includeSubDomains; preload;


curl -v  -o /dev/null -F "filecontent=@1g.iso" https://www.arcep.fr
ca fonctionne:
* h2h3 [:method: POST]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: www.arcep.fr]
* h2h3 [user-agent: curl/7.86.0]
* h2h3 [accept: */*]
* h2h3 [content-length: 1000000205]
* h2h3 [content-type: multipart/form-data; boundary=------------------------9338e6b795672709]
* Using Stream ID: 1 (easy handle 0x56215a9e6e60)

tu vas me dire c'est un cache Varnish pas un serveur Apache.
Mais sur https://lafibre.info ca marche aussi.

alors que la meme commande sur https://bouygues.testdebit.info donne:

curl: (92) Stream error in the HTTP/2 framing layer
avec un fichier moins gros ca passe:
* h2h3 [:method: POST]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: bouygues.testdebit.info]
* h2h3 [user-agent: curl/7.86.0]
* h2h3 [accept: */*]
* h2h3 [content-length: 1229]
* h2h3 [content-type: multipart/form-data; boundary=------------------------121e358fb001866d]
* Using Stream ID: 1 (easy handle 0x55f98b125e60)

alors qu'en http1.1 ca passe meme avec 1G.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 19 novembre 2022 à 22:27:02
Oh, l'upload fonctionne avec lafibre.info en HTTP/2 !

C'est une découverte que je ne saurerai pas expliquer pourquoi.

Il va falloir jouer au jeu des 7 différences, car c'est très proche avec les autres serveurs en termes de configuration Apache.

Si tu as une idée de quoi regarder, en regardant rapidement, cela ne saute pas aux yeux.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 20 novembre 2022 à 14:43:45
T'as rien en frontal devant lafibre.info même un truc transparent ou chez un provider ?

J'avoue que c'est curieux et l'erreur de curl aussi. Avec nspeed je ne vois même pas d'erreur, ca coupe juste l'upload car le serveur renvoi de suite la page d'accueil comme un GET en fait.
mon explication est que POST ou GET c'est pareil pour https://bouygues.testdebit.info et si on envoi trop de data ca doit saturer un buffer a un moment et arrêter le flux http/2 ?



Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 20 novembre 2022 à 19:03:28
Rien en frontal sur LaFibre.info, aucun accélérateurs (APC, eAccelerator, Turck MMCache, Memcached, Zend Platform,...).

La seule chose spéciale, c'est le fait d'avoir un opérateur pour l'IPv4 (MilkyWan sur ETH1) et un opérateur pour IPv6 (Adeli sur ETH0).

La conf, que ce soit Apache ou PHP est très similaire entre Bouygues et LaFibre.info.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 21 novembre 2022 à 14:42:14
La conf, que ce soit Apache ou PHP est très similaire entre Bouygues et LaFibre.info.

T'as du php sur la racine de bouygues.testdebit.info ?

c'est peu-etre ca la différence.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 21 novembre 2022 à 14:44:46
Pas de PHP à la racine.

Il y a du PHP configuré sur le serveur pour le fichier upload.php
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 22 novembre 2022 à 13:05:42
analyse sur un Ubuntu 22.04.1 LTS. tl:dr:  voir "5. conclusion"

1 - install apache2 (apres un clean profond)
             sudo apt-get --purge remove apache2* && sudo apt-get autoremove && sudo rm -r /etc/apach2 /var/lib/apache2
             sudo apt install apache2 apache2-utils ssl-cert
test get http://localhost ok (landing page d'apache 2 ubuntu)
test upload 10G sur / en http (avec curl -F): ok

lors d'un upload (POST) le serveur répond un 404 car il n'y rien par défaut pour traiter un POST sur '/'. Mais en HTTP 1.1 le client envoi quand meme toute les data.

2 - activation http/2:
             sudo a2enmod http2 ssl
             création d'un vhost pour 433 (certificat locaux; affichage d'un répertoire).
             redémarrage apache2
test get https://localhost : ok
test upload 10G sur https://localhost: erreur  ("Stream error in the HTTP/2 framing layer")
test upload 10G sur https://localhost en forcant http1.1 : ok

c'est bien HTTP/2 (et pas le chiffrement) qui pose problème donc.
ce qui semble normal vu le fonctionnement d'http/2 car on fait un POST (entete+data) , le serveur reçoit les trames d'entete, traite de suite et renvoi la réponse (un 404 ou un 200 suivant le path demandé) et ferme le stream  (on voit bien le 'stream 0 closed' avec curl -v). Et donc ne consomme jamais la suite des trames de data (en http1.1 c'est un seul flux entete+data).

(https://web-dev.imgix.net/image/C47gYyWYVMMhDmtYSLOWazuyePF2/2a2cw0nAXe9Mi5txM4Mw.svg)
(source : https://web.dev/performance-http2/ )

=> Il manque donc quelque chose coté serveur pour traiter les POST en "consommant" tout le stream y compris les trames data.

C'est normal car de base apache2 ne gere que du contenu statique. cela fait pareil avec nginx d'ailleurs.

Il manque donc un "handler" pour traiter les POST et consommer la data.

3 - installation de php
         sudo apt install php-fpm libapache2-mod-php
         redémarrage d'apache2:
test upload 10G: erreur, aucun changement . normal.

4. activation de php:
          sudo a2enmod proxy_fcgi setenvif
          redémarrage d'apache2:
test upload 10G: erreur, aucun changement . normal.
          sudo systemctl start php8.1-fpm
          sudo systemctl enable php8.1-fpm
          sudo a2enconf php8.1-fpm
          redémarrage d'apache2:
test upload 10G: erreur, aucun changement . normal.

creation d'un simple fichier hello.php dans la répertoire racine:
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<body> 
  <?php echo "Hello World"?>
</body>
</html>

redémarrage d'apache2:
test upload 10G: erreur, aucun changement . normal.

test php:
curl  https://localhost/hello.php
-> ok on a bien hello world
test upload 10G sur https://localhost/: erreur, aucun changement . normal.
test upload 10G sur https://localhost/hello.php -> OK !

5. conclusion:
tout semble logique donc, il faut un 'handler' qui consomme la data.

un moyen si php est installé est d'activer le handler sur  la racine '/':
        <Directory "/some/path">
                ....
                SetHandler "proxy:unix:/run/php/php8.1-fpm.sock|fcgi://localhost"
                ...
        </Directory>
comme n'importe quel url va passer par le handler php et pas seulement ceux terminant par .php
Tu peux aussi ne matcher que '/' et pas un sous chemin avec un LocationMatch:

        <LocationMatch "^/$">
                SetHandler "proxy:unix:/run/php/php8.1-fpm.sock|fcgi://localhost"
        </LocationMatch>

l'avantage ainsi c'est tes fichiers statiques /10G/10G.iso par exemple, ne passeront pas par le handler php en sortie sur un GET.
ou alors ne mettre le handler que si c'est POST. etc

bon pres utiliser le handler php pour consommer des données n'est peut-etre pas la meilleur des méthodes. Il faudrait voir si y'a un mod ou une config qui permet de consommer tout un POST sans impact sur le serveur.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 22 novembre 2022 à 14:56:39
Donc en fait, il n'y a rien à faire de mon côté.

Il faut que j'indique la bonne url pour l'upload : https://bouygues.testdebit.info/ul/upload.php

Avec curl :
curl -o /dev/null -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/upload.php

Je vais mettre à jour la page d'accueil pour indiquer l'URL d'upload (c'est /ul/upload.php sur les serveurs que je gére)
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 22 novembre 2022 à 15:56:51
Donc en fait, il n'y a rien à faire de mon côté.

Il faut que j'indique la bonne url pour l'upload : https://bouygues.testdebit.info/ul/upload.php

Avec curl :
curl -o /dev/null -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/upload.php

Je vais mettre à jour la page d'accueil pour indiquer l'URL d'upload (c'est /ul/upload.php sur les serveurs que je gére)

oui si ton fichier upload.php ne fait pas de stockage des données récus sinon tu vas saturer ton serveur.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 22 novembre 2022 à 16:22:43
de ce que a posté précedement:

<?php
$datas 
file_get_contents(&#38;#39;php://input&#38;#39;);
$resultArray["status"] = "FICHIER RECU";
...

pas certain que file_get_contents soit le mieux pour les gros upload.

idéalement utilise un fichier php sans code php dedans.

apres si Apache2 est mal 'tuner' pour http/2 ca peut aussi être lent.
il faut notamment:
H2WindowSize 1048576dans /etc/apache2/mods-enabled/http2.conf
car la valeur par défaut est 64k je crois.
Cloudflare a benchmarké cela: https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
ils recommendent au moins 256k. Avec 1M t'es tranquille je pense.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 22 novembre 2022 à 16:32:52
ton handler ul/upload.php:

./nspeed post --http2 https://bouygues.testdebit.info/ul/upload.php 1g post --http1.1 https://bouygues.testdebit.info/ul/upload.php 1g
Jobs:
  0-HTTP POST https://bouygues.testdebit.info/ul/upload.php
  1-HTTP POST https://bouygues.testdebit.info/ul/upload.php
running...
all done
   Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
 Job 0|      0 bps|  173.0 Mbps| 7.98|        0 B|      172.7 MB|post -http2 https://bouygues.testdebit.info/ul/upload.php 1.0 GB (89.84.1.186:443 - 3.817 ms - )
 Job 1|      0 bps|  736.1 Mbps| 7.99|        0 B|      734.7 MB|post -http1.1 https://bouygues.testdebit.info/ul/upload.php 1.0 GB (89.84.1.186:443 - 3.505 ms - )
 Total|      0 bps|  909.0 Mbps| 7.99|        0 B|      907.4 MB|

seul ca dépasse jamais 200 Mbps en upload avec HTTP/2.

avec 4 flux:

./nspeed post -n 4 --http2 https://bouygues.testdebit.info/ul/upload.php 1g
Jobs:
  0-HTTP POST https://bouygues.testdebit.info/ul/upload.php
  1-HTTP POST https://bouygues.testdebit.info/ul/upload.php
  2-HTTP POST https://bouygues.testdebit.info/ul/upload.php
  3-HTTP POST https://bouygues.testdebit.info/ul/upload.php
running...
all done
   Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
 Job 0|      0 bps|  225.0 Mbps| 7.98|        0 B|      224.6 MB|post -http2 https://bouygues.testdebit.info/ul/upload.php 1.0 GB (89.84.1.186:443 - 2.985 ms - )
 Job 1|      0 bps|  222.8 Mbps| 7.99|        0 B|      222.4 MB|post -http2 https://bouygues.testdebit.info/ul/upload.php 1.0 GB (89.84.1.186:443 - 3.84 ms - )
 Job 2|      0 bps|  220.5 Mbps| 7.99|        0 B|      220.1 MB|post -http2 https://bouygues.testdebit.info/ul/upload.php 1.0 GB (89.84.1.186:443 - 3.145 ms - )
 Job 3|      0 bps|  224.3 Mbps| 7.98|        0 B|      223.7 MB|post -http2 https://bouygues.testdebit.info/ul/upload.php 1.0 GB (89.84.1.186:443 - 4.158 ms - )
 Total|      0 bps|  892.4 Mbps| 7.99|        0 B|      890.7 MB|

Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 22 novembre 2022 à 17:33:38
J'ai mis en place https://bouygues.testdebit.info/ul/

Le fichier index.php qui est appelé quand on va sur cette URL est minimaliste :
<!DOCTYPE html>
<html lang="fr">
 <head><title>Net-test</title></head>
 <body><?php echo "<p>URL pour réaliser un test de débit montant</p>"?></body>
</html>

Je vais faire quelques tests pour H2WindowSize et H2StreamMaxMemSize.

Merci d'avoir vu que la valeur par défaut n'est pas pertinente pour un test de débit.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 22 novembre 2022 à 18:26:43
J'ai mis H2WindowSize 16777216 dans /etc/apache2/mods-enabled/http2.conf

16 Mo est la valeur qui était configurée pour TCP (et donc utilisé pour HTTP/1.1) :

3/ Optimisations réseau et swappiness :

nano /etc/sysctl.d/90-server-optimization.conf
Copier / coller le texte ci-dessous dans le fichier :
# Reduce the swap
vm.swappiness = 1

# TCP congestion control protocol for high-speed and long-distance networks
net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq

# Disable the memorization of previous tests, in order to avoid that the server burns the tests following a limited performance
net.ipv4.tcp_no_metrics_save=1

# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216

# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000

# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096

# Increase number of incoming connections
net.core.somaxconn = 4096

Avec une latence de 200ms (simulée via NetEm (https://lafibre.info/tutoriels-linux/generer-des-pertes-de-paquets/)) cela améliore bien les résultats, toutefois le débit montant s'écroule, après quelques secondes, mais c'est peut-être lié au proxy du travail. Il faut que je teste depuis un accès internet neutre.

Je n'ai pas encore défini la bonne valeur pour H2StreamMaxMemSize
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 23 novembre 2022 à 22:03:41
J'ai donc commencé par réaliser des tests, depuis ma ligne SFR FttH 1 Gb/s symétrique, en rajoutant 200 ms via NetEM pour avoir une latence de 204 ms bout en out avec le serveur.

Contenu du fichier /etc/apache2/mods-enabled/http2.conf
<IfModule !mpm_prefork>
    Protocols h2 h2c http/1.1
    H2WindowSize 16777216
</IfModule>

Serveur Cubic / Latence 204ms / WindowSize serveur 16 Mo / WindowSize client valeur par défaut :
- Descendant HTTP/1.1 en clair : curl --http1.1 -o /dev/null http://bouygues.testdebit.info/1G.iso => 14,2 Mo/s
- Descendant HTTP/1.1 chiffré : curl --http1.1 -o /dev/null https://bouygues.testdebit.info/1G.iso => 14,0 Mo/s
- Descendant HTTP/2 en clair : curl --http2 -o /dev/null http://bouygues.testdebit.info/1G.iso => 14,2 Mo/s
- Descendant HTTP/2 chiffré : curl --http2 -o /dev/null https://bouygues.testdebit.info/1G.iso => 14,1 Mo/s

- Montant HTTP/1.1 en clair : curl --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/ => 10,3 Mo/s
- Montant HTTP/1.1 chiffré : curl --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/ => 9,89 Mo/s
- Montant HTTP/2 en clair : curl --http2 -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/ => 10,2 Mo/s
- Montant HTTP/2 chiffré : curl --http2 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/ => 0,687 Mo/s


Les résultats sont mauvais, j'impute ça sur la WindowSize de mon client, un Ubuntu 22.10 avec les paramètres par défaut. Je monte donc la WindowSize du client à 16 Mo, comme sur le serveur :

Serveur Cubic / Latence 204ms / WindowSize serveur 16 Mo / WindowSize client 16 Mo :
- Descendant HTTP/1.1 en clair : curl --http1.1 -o /dev/null http://bouygues.testdebit.info/1G.iso => 19,0 Mo/s
- Descendant HTTP/1.1 chiffré : curl --http1.1 -o /dev/null https://bouygues.testdebit.info/1G.iso => 17,9 Mo/s
- Descendant HTTP/2 en clair : curl --http2 -o /dev/null http://bouygues.testdebit.info/1G.iso => 18,8 Mo/s
- Descendant HTTP/2 chiffré : curl --http2 -o /dev/null https://bouygues.testdebit.info/1G.iso => 20,1 Mo/s

- Montant HTTP/1.1 en clair : curl --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/ => 17,8 Mo/s
- Montant HTTP/1.1 chiffré : curl --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/ => 17,2 Mo/s
- Montant HTTP/2 en clair : curl --http2 -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/ => 21,5 Mo/s
- Montant HTTP/2 chiffré : curl --http2 -o /dev/null -F "file=@/tmp/temp.iso" https://bouygues.testdebit.info/ul/ => 0,616 Mo/s

Modification des paramètres serveur H2StreamMaxMemSize 65536 => H2StreamMaxMemSize 16777216
Contenu du fichier /etc/apache2/mods-enabled/http2.conf
<IfModule !mpm_prefork>
    Protocols h2 h2c http/1.1
    H2WindowSize 16777216
    H2StreamMaxMemSize 16777216
</IfModule>

- Descendant HTTP/2 en clair :  18,8 Mo/s => 21,2 Mo/s (résultats très proches vu les variations de débit en Cubic)
- Descendant HTTP/2 chiffré : 20,1 Mo/s => 19,5 Mo/s (résultats très proches vu les variations de débit en Cubic)
- Montant HTTP/2 en clair : 21,5 Mo/s => 21,4 Mo/s (résultats très proches vu les variations de débit en Cubic)
- Montant HTTP/2 chiffré : 0,616 Mo/s => 2,44 Mo/s
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 23 novembre 2022 à 22:37:24
Les débits dans les tests précédant ont tendance a pas mal fluctuer. J'ai relevé le débit moyen sur un fichier de 1 Go, mais la moyenne est bien entachée par des baisses de débit.

Je recommence donc l'expérience avec un serveur BBR (même latence, même configuration excepté Cubic remplacé par BBR) et client BBR.

Serveur BBR / Latence 204ms / WindowSize serveur 16 Mo / WindowSize client 16 Mo :
- Descendant HTTP/1.1 en clair : curl --http1.1 -o /dev/null http://paris.testdebit.info/1G.iso => 34,7 Mo/s
- Descendant HTTP/1.1 chiffré : curl --http1.1 -o /dev/null https://paris.testdebit.info/1G.iso => 33,6 Mo/s
- Descendant HTTP/2 en clair : curl --http2 -o /dev/null http://paris.testdebit.info/1G.iso => 32,2 Mo/s
- Descendant HTTP/2 chiffré : curl --http2 -o /dev/null https://paris.testdebit.info/1G.iso => 32,7 Mo/s

- Montant HTTP/1.1 en clair : curl --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" http://paris.testdebit.info/ul/ => 34,1 Mo/s
- Montant HTTP/1.1 chiffré : curl --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://paris.testdebit.info/ul/ => 34,2 Mo/s
- Montant HTTP/2 en clair : curl --http2 -o /dev/null -F "file=@/tmp/temp.iso" http://paris.testdebit.info/ul/ => 34,7 Mo/s
- Montant HTTP/2 chiffré : curl --http2 -o /dev/null -F "file=@/tmp/temp.iso" https://paris.testdebit.info/ul/ => 0,594 Mo/s

Modification des paramètres serveur H2StreamMaxMemSize 65536 => H2StreamMaxMemSize 16777216
Contenu du fichier /etc/apache2/mods-enabled/http2.conf
<IfModule !mpm_prefork>
    Protocols h2 h2c http/1.1
    H2WindowSize 16777216
    H2StreamMaxMemSize 16777216
</IfModule>

- Descendant HTTP/2 en clair :  32,2 Mo/s => 33,1 Mo/s (résultats très proches)
- Descendant HTTP/2 chiffré : 32,7 Mo/s => 30,4 Mo/s (résultats très proches)
- Montant HTTP/2 en clair : 34,7 Mo/s => 35,0 Mo/s (résultats très proches)
- Montant HTTP/2 chiffré : 0,594 Mo/s => 2,080 Mo/s

Conclusion :
- Il y a un problème sur le débit Montant HTTP/2 chiffré
- Le gain apporté par "H2StreamMaxMemSize 16777216" n'est pas évident, je me demande si c'est une bonne idée de modifier cette variable.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 23 novembre 2022 à 22:58:23
Même test, uniquement en HTTP/2 avec une faible latence (4ms) sur un serveur BBR :

Serveur BBR / Latence 4ms / WindowSize serveur 16 Mo / WindowSize client 16 Mo :
- Descendant HTTP/2 en clair : curl --http2 -o /dev/null http://paris.testdebit.info/1G.iso => 111 Mo/s
- Descendant HTTP/2 chiffré : curl --http2 -o /dev/null https://paris.testdebit.info/1G.iso => 110 Mo/s

- Montant HTTP/1.1 en clair : curl --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" http://paris.testdebit.info/ul/ => 110 Mo/s
- Montant HTTP/1.1 chiffré : curl --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://paris.testdebit.info/ul/ => 110 Mo/s
- Montant HTTP/2 en clair : curl --http2 -o /dev/null -F "file=@/tmp/temp.iso" http://paris.testdebit.info/ul/ => 110 Mo/s
- Montant HTTP/2 chiffré : curl --http2 -o /dev/null -F "file=@/tmp/temp.iso" https://paris.testdebit.info/ul/ => 28,4 Mo/s

Modification des paramètres serveur H2StreamMaxMemSize 65536 => H2StreamMaxMemSize 16777216
Contenu du fichier /etc/apache2/mods-enabled/http2.conf
<IfModule !mpm_prefork>
    Protocols h2 h2c http/1.1
    H2WindowSize 16777216
    H2StreamMaxMemSize 16777216
</IfModule>

- Descendant HTTP/2 en clair :  111 Mo/s => 111 Mo/s (résultats très proches)
- Descendant HTTP/2 chiffré : 110 Mo/s => 96,9 Mo/s
- Montant HTTP/2 en clair : 110 Mo/s => 109 Mo/s (résultats très proches)
- Montant HTTP/2 chiffré : 28,4 Mo/s => 37,0 Mo/s

J'ai refait de nombreuses fois le test descendant HTTP/2 chiffré avec et sans H2StreamMaxMemSize 16777216 et je confirme que H2StreamMaxMemSize 16777216 fait baisser le débit sensiblement.

J'ai donc remis les serveurs Bouygues.testdebit.info et paris.testdebit.info avec la valeur par défaut (H2StreamMaxMemSize 65536)
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 23 novembre 2022 à 23:22:29
il n'y a pas d'HTTP/2 en clair dans tes tests la. L'option --http2 avec un url en "http:..." fera du HTTP1.1 (curl --http2 n'impose pas HTTP/2 , c'est juste qu'il le préfère s'il est dispo).
Pour faire du HTTP/2 sans chiffrement , c'est H2C. il faut que ton serveur le supporte  (a priori oui) et utiliser l'option curl "--http2-prior-knowledge" et "http:" dans l'url.

Vérifies toujours dans tests le protocole HTTP réellement utilisé: remplace '-o /dev/null' par '-i' ca affichera le proto (en utilisant un petit fichier en upload ou download). pour voir le chiffrement utilisé -v.

Le BPR (Bandwidth*Delay Product) donne en théorie pour 1 Gbps et 16Mo de buffer un délai max de 130ms. Pour atteindre 1 Gbps avec 200ms il faut 23 Mo de buffer.

H2StreamMaxMemSize ne concerne que les flux sortants du serveur. cf https://httpd.apache.org/docs/2.4/mod/mod_http2.html#h2streammaxmemsize
H2WindowSize ne concerne que les flux entrants sur le serveur.
Dans les  2 cas se sont les buffers du mod_http2 d'apache, en dessous y'a les buffers de l'OS et au dessus les buffers applicatifs (de php dans le cas présent).

Sur ma ligne FeePro 1Gbps upload vers paris.testdebit.info (4 ms de latence):

http1.1 chiffré ou non: 118 Mo/s
http2 non chiffré: 54 Mo/s
http2 chiffré : 30 Mo/s
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 24 novembre 2022 à 09:16:04
Exact, il faut utiliser --http2-prior-knowledge pour un flux en clair.
J'ai pris une latence de 200ms de façon à être sûr que la fenêtre TCP soit l'élément limitant.

J'ai réalisé de nouveaux tests avec les valeurs par défaut coté serveur :

Serveur BBR / Latence 204ms / WindowSize serveur 65535 octets / WindowSize client 16 Mo :
- Descendant HTTP/1.1 en clair : curl --http1.1 -o /dev/null http://paris.testdebit.info/1G.iso => 34,5 Mo/s
- Descendant HTTP/1.1 chiffré : curl --http1.1 -o /dev/null https://paris.testdebit.info/1G.iso => 34,9 Mo/s
- Descendant HTTP/2 en clair : curl --http2-prior-knowledge -o /dev/null http://paris.testdebit.info/1G.iso => 34,2 Mo/s
- Descendant HTTP/2 chiffré : curl --http2 -o /dev/null https://paris.testdebit.info/1G.iso => 32,8 Mo/s

- Montant HTTP/1.1 en clair : curl --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" http://paris.testdebit.info/ul/ => 35,0 Mo/s
- Montant HTTP/1.1 chiffré : curl --http1.1 -o /dev/null -F "file=@/tmp/temp.iso" https://paris.testdebit.info/ul/ => 34,5 Mo/s
- Montant HTTP/2 en clair : curl --http2-prior-knowledge -o /dev/null -F "file=@/tmp/temp.iso" http://paris.testdebit.info/ul/ => 0,474 Mo/s
- Montant HTTP/2 chiffré : curl --http2 -o /dev/null -F "file=@/tmp/temp.iso" https://paris.testdebit.info/ul/ => 0,282 Mo/s

Serveur BBR / Latence 204ms / WindowSize serveur 16 Mo / WindowSize client 16 Mo :
- Montant HTTP/2 en clair : curl --http2-prior-knowledge -o /dev/null -F "file=@/tmp/temp.iso" http://paris.testdebit.info/ul/ => 0,918 Mo/s
- Montant HTTP/2 chiffré : curl --http2 -o /dev/null -F "file=@/tmp/temp.iso" https://paris.testdebit.info/ul/ => 0,584 Mo/s

Avec H2WindowSize 16777216, on gagne en débit montant en HTTP/2, mais il y a un élément qui limite la fenêtre quelque part. Curl ?

Coté OS client, j'ai :
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216

Pour H2StreamMaxMemSize, j'ai l'impression, que c'est plus pour un serveur qui a du mal à générer les données que cela peut être intéressant d'augmenter la taille.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 24 novembre 2022 à 12:03:20

Avec H2WindowSize 16777216, on gagne en débit montant en HTTP/2, mais il y a un élément qui limite la fenêtre quelque part. Curl ?


curl ... peut-etre. en principe curl utilise nghttp2 (visible avec curl -V).
tu peux installer le client nghttp2 pour faire des tests directs et voir si curl influe.

sudo apt install nghttp2-client

depuis mon Ubuntu  Ubuntu 22.04.1 LTS ca donne:
curl -V
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

nghttp --version
nghttp nghttp2/1.43.0

donc nghttp2/1.43.0

nghttp -s -n  -d /path/to/1G.dat http://paris.testdebit.info/ul/
pour faire un POST.

apres j'ai constaté que ce n'est pas stable en upload, ca oscille en 20 Mo/s et 50 Mo/s (avec curl).
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 24 novembre 2022 à 17:50:46
si tu ne veux pas trop perdre de temps, je te recommande quand meme de verifier que le souci n'est pas coté serveur Apache...

Tu peux eventuellement tester avec nginx qui a été optimisé pour HTTP/2
ou
Tu peux utiliser cette version 'light' de nspeed ici: https://github.com/nspeed-app/http2issue/releases/tag/v0.0.2
Ce binaire Linux ("nspeed-mini-linux-amd64") permet d'avoir un serveur http1.1 et http/2 sans chiffrement.
en le lancant avec l'option -s:
./nspeed-mini-linux-amd64 -stu aura 2 ports en écoute
server created and listening at 8765 (http1.1)
server created and listening at 9876 (http/2 cleartext)

tu peux faire des get et post dessus:
get:
curl -o /dev/null http://ip_du_serveur:8765/1000000000(il suffit de mettre une taille en octets apres le /)
post:
curl -F "file=@/path/to/1G.dat" http://localhost:8765/le serveur va répondre avec le débit donc ne pas mettre de redirection vers /dev/null
pour http/2
il faut utiliser l'option cleartext de curl donc --http2-prior-knowledge et le port 9876

Ca devrait déja te permettre de savoir si le souci vient d'Apache ou du client curl.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 24 novembre 2022 à 21:45:39
Serveur : BBR, avec WindowSize de 16 Mo, OS  Ubuntu 22.04.1, hébergé par Bouygues (iso emplacement et configuration avec paris.testdebit.info) : nspeed.testdebit.info
Client : BBR, avec WindowSize de 16 Mo, OS : Ubuntu 22.10, lige FTTH RED 1 Gb/s symétrique

Latence de 4ms :
- Descendant HTTP/1.1 en clair : curl --http1.1 -o /dev/null http://nspeed.testdebit.info:8765/1000000000 => 111 Mo/s
- Descendant HTTP/2 en clair : curl --http2-prior-knowledge -o /dev/null http://nspeed.testdebit.info:9876/1000000000 => 111 Mo/s
- Montant HTTP/1.1 en clair : curl --http1.1 -o /dev/null -F "file=@/home/vgu/snap/1G.iso" http://nspeed.testdebit.info:8765/ => 110 Mo/s
- Montant HTTP/2 en clair : curl --http2-prior-knowledge -o /dev/null -F "file=@/home/vgu/snap/1G.iso" http://nspeed.testdebit.info:9876/ => 109 Mo/s

Latence de 204ms : (+200ms simulée via NetEm)
- Descendant HTTP/1.1 en clair : curl --http1.1 -o /dev/null http://nspeed.testdebit.info:8765/1000000000 => 34,4 Mo/s
- Descendant HTTP/2 en clair : curl --http2-prior-knowledge -o /dev/null http://nspeed.testdebit.info:9876/1000000000 => 33,6 Mo/s
- Montant HTTP/1.1 en clair : curl --http1.1 -o /dev/null -F "file=@/home/vgu/snap/1G.iso" http://nspeed.testdebit.info:8765/ => 35,5 Mo/s
- Montant HTTP/2 en clair : curl --http2-prior-knowledge -o /dev/null -F "file=@/home/vgu/snap/1G.iso" http://nspeed.testdebit.info:9876/ => 4,83 Mo/s

Conclusion : les résultats montrent d'excellentes performances avec nspeed, sauf pour le test montant HTTP/2. Les résultats sont meilleurs qu'avec Apache, car le débit est constant vers 5 Mo/s là où le débit chute avec apache, ce qui donne une moyenne plus faible.

Il y a clairement un problème avec Curl.

nspeed.testdebit.info reste en ligne si vous souhaitez tester.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 24 novembre 2022 à 22:23:52
si on résume, avec latence , le sens client->serveur en http/2 n'est pas bon.

du coup c'est soit un problème de buffer sortant coté curl  ou buffer entrant coté serveur ?

Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 24 novembre 2022 à 22:29:09
La configuration des buffers système coté serveur (et coté client également) :

nano /etc/sysctl.d/90-server-optimization.conf
Copier / coller le texte ci-dessous dans le fichier :
# Reduce the swap
vm.swappiness = 1

# TCP congestion control protocol for high-speed and long-distance networks
net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq

# Disable the memorization of previous tests, in order to avoid that the server burns the tests following a limited performance
net.ipv4.tcp_no_metrics_save=1

# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216

# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000

# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096

# Increase number of incoming connections
net.core.somaxconn = 4096
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: zergflag le 01 février 2023 à 13:26:25
C'est moi ou http://bouygues.testdebit.info est down ?

Idem chez moi
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 01 février 2023 à 13:47:18
Merci, c'est réparé.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: zergflag le 01 février 2023 à 14:53:30
Merci, c'est réparé.

Toujours down perso pour moi
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: simon le 01 février 2023 à 16:29:52
$ curl -6 https://bouygues.testdebit.info -v -o /dev/null
Trying 2001:860:de01:1100::2:443...
* connect to 2001:860:de01:1100::2 port 443 failed: Connection refused
curl: (7) Failed to connect to bouygues.testdebit.info port 443: Connection refused

$ ping bouygues.testdebit.info
PING bouygues.testdebit.info(2001:860:de01:1100::2 (2001:860:de01:1100::2)) 56 data bytes
64 bytes from 2001:860:de01:1100::2 (2001:860:de01:1100::2): icmp_seq=1 ttl=54 time=9.17 ms
64 bytes from 2001:860:de01:1100::2 (2001:860:de01:1100::2): icmp_seq=2 ttl=54 time=8.84 ms
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: zergflag le 01 février 2023 à 16:46:56
curl --head http://bouygues.testdebit.info/
curl: (7) Failed to connect to bouygues.testdebit.info port 80 after 2286 ms: Connection refused

curl --head https://bouygues.testdebit.info/
curl: (7) Failed to connect to bouygues.testdebit.info port 443 after 2285 ms: Connection refused

curl -4 --head https://bouygues.testdebit.info/
curl: (7) Failed to connect to bouygues.testdebit.info port 443 after 2082 ms: Connection refused

curl -6 --head https://bouygues.testdebit.info/
curl: (7) Failed to connect to bouygues.testdebit.info port 443 after 2078 ms: Connection refused

curl -4 --head http://bouygues.testdebit.info/
curl: (7) Failed to connect to bouygues.testdebit.info port 80 after 2088 ms: Connection refused

curl -6 --head http://bouygues.testdebit.info/
curl: (7) Failed to connect to bouygues.testdebit.info port 80 after 2073 ms: Connection refused
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 01 février 2023 à 19:18:55
Le serveur Ookla n'a pas arrêté de fonctionner, mais apache, si par manque de mémoire vive.

Il y a une sorte de DDOS qui utilise les 32 Go de ram et le CPU :
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 01 février 2023 à 19:21:24
Voici les logs Apache :
[Wed Feb 01 13:44:51.353645 2023] [mpm_event:notice] [pid 1486:tid 140591404627840] AH00489: Apache/2.4.52 (Ubuntu) OpenSSL/3.0.2 configured -- resuming normal operations
[Wed Feb 01 13:44:51.353825 2023] [core:notice] [pid 1486:tid 140591404627840] AH00094: Command line: '/usr/sbin/apache2'
[Wed Feb 01 14:13:27.445208 2023] [mpm_event:notice] [pid 1486:tid 140591404627840] AH00492: caught SIGWINCH, shutting down gracefully
[Wed Feb 01 14:13:30.802650 2023] [core:warn] [pid 1486:tid 140591404627840] AH00045: child process 1489 still did not exit, sending a SIGTERM
[Wed Feb 01 14:13:30.802696 2023] [core:warn] [pid 1486:tid 140591404627840] AH00045: child process 1490 still did not exit, sending a SIGTERM
[Wed Feb 01 14:13:30.802710 2023] [core:warn] [pid 1486:tid 140591404627840] AH00045: child process 1491 still did not exit, sending a SIGTERM
[Wed Feb 01 14:13:30.802721 2023] [core:warn] [pid 1486:tid 140591404627840] AH00045: child process 1492 still did not exit, sending a SIGTERM
[Wed Feb 01 14:13:30.802732 2023] [core:warn] [pid 1486:tid 140591404627840] AH00045: child process 1509 still did not exit, sending a SIGTERM
[Wed Feb 01 14:13:30.802741 2023] [core:warn] [pid 1486:tid 140591404627840] AH00045: child process 1536 still did not exit, sending a SIGTERM
...


J'ai relancé et je surveille.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: zergflag le 01 février 2023 à 19:41:11
Vivien j'ai pas envie de te froisser mais pour ce type de service, ça ne serait pas mieux d'utiliser nginx ?
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 01 février 2023 à 20:28:21
Apache a plusieurs moteurs différents, appelés MPM.

Voici les MPM par défaut d'Apache en fonction du système :
- BeOS: beos
- Netware: mpm_netware
- OS/2: mpmt_os2
- Unix: prefork
- Windows: mpm_winnt

Le plus connu, le mpm prefork (c'est habituellement lui qui est installé dans les tutoriels avec PHP) est peu performant.

On peut lui préférer Nginx, mais Apache a un moteur proche de Nginx : le mpm event.
=> https://httpd.apache.org/docs/2.4/fr/mod/event.html
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: piwik le 16 avril 2023 à 03:20:59
Bonjour a tous. Je ne sais pas si cela vient de chez moi, mais j ai le meme probleme :

 curl -4 -o /dev/null https://bouygues.testdebit.info/1G.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (7) Failed to connect to bouygues.testdebit.info port 443 after 38 ms: Connection refused

Pareil en HTTP :

curl -4 -o /dev/null http://bouygues.testdebit.info/1G.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (7) Failed to connect to bouygues.testdebit.info port 80 after 16 ms: Connection refused

Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: hwti le 16 avril 2023 à 04:42:07
En effet, le serveur ne répond pas.
Les autres comme paris.testdebit.info fonctionnent bien.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 16 avril 2023 à 08:56:11
Désolé, Apache a été tué par un manque de mémoire dans ce qui ressemble à une attauqe. Impréssionant de voir un OOM sur un serveur avec 32 Go de ram (mais c'est vrai que je ne mets que quelques Go de SWAP)

apache2.service: A process of this unit has been killed by the OOM killer.
apache2.service: Killing process 1577912 (apache2) with signal SIGKILL.
apache2.service: Killing process 1578320 (apache2) with signal SIGKILL.
apache2.service: Killing process 1609348 (apache2) with signal SIGKILL.
apache2.service: Failed with result 'oom-kill'.
apache2.service: Consumed 1w 3d 19h 22min 8.114s CPU time.


C'est relancé.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: piwik le 16 avril 2023 à 11:34:26
Super ca fonctionne parfaitement a present. merci
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: m@rco123 le 30 avril 2023 à 07:37:51
perso,, je me suis fais ca depuis la chute de  bouygues.testdebit.info et de speedtest.cli

Citer
#!/bin/bash

# Creation du fichier de mesure
echo "HEURE DL UL PING" > speedtest.csv

# comme ca, un " ctrl c " arrete tout
for i in `seq 1 1 100000`;
do

# calcul download
#dl=($(curl -o /dev/null http://bouygues.testdebit.info/100M.iso 2>&1))
dl=($(curl -o /dev/null http://paris.testdebit.info/100M.iso 2>&1))

# calcul upload
#ul=($(curl --max-time 60 -4 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/ 2>&1))
ul=($(curl --max-time 60 -4 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" http://paris.testdebit.info/ul/ 2>&1))

# calcul ping
pg=$(LC_ALL=C ping -c1 1.1.1.1 | sed -e '/time=/!d' -e 's|^.*time=\([\.[:digit:]]\+\) ms$|\1|')

# heure
dte=$(date "+%T")

# inscription dans le fichier et à l'ecran
echo $dte "${dl[-6]:0:-1}" "${ul[-6]:0:-1}" $pg >> speedtest.csv
echo $i $dte "${dl[-6]:0:-1}" "${ul[-6]:0:-1}" $pg

# pour 1 minute entre chaque test à modifier selon usage
sleep 1m

done
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 30 avril 2023 à 15:35:02
Même problème que la dernière fois, j'ai relancé.

Il faut(t que je comprenne la cause du probléme.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: fregate84 le 06 juillet 2023 à 20:03:55
Les fichiers 1Go et 10Go semble down, non ?

- Exemple avec un fichier de 1 Go : curl -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso
- Exemple avec un fichier de 10 Go : curl -o /tmp/temp.iso https://bouygues.testdebit.info/10G.iso
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 06 juillet 2023 à 20:47:34
Encore apache qui a été tué :

juil. 03 12:28:14 nperf1-ntr systemd[1]: apache2.service: A process of this unit has been killed by the OOM killer.
juil. 03 12:28:15 nperf1-ntr apachectl[510545]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using ::1. Set the 'ServerName' directive globally t>
juil. 03 12:28:26 nperf1-ntr systemd[1]: apache2.service: Failed with result 'oom-kill'.
juil. 03 12:28:26 nperf1-ntr systemd[1]: apache2.service: Consumed 17h 12min 57.694s CPU time.

Je ne comprends pas pourquoi. J'ai modifié la configuration d'Apache pour limiter les process, cela ne change rien. C'est le seul serveur où j'ai ce problème, et il a pourtant 32 Go de ram.

En désespoir de cause, j'ai modifié vm.swappiness = 1 par vm.swappiness = 10 toutefois, j'aimerais bien comprendre la root cause.

J'ai redémarré le serveur.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: hwti le 07 juillet 2023 à 01:15:44
Il faut regarder les logs kernel sur l'oom-killer : est-ce qu'il y avait beaucoup de processus, ou au contraire un processus apache consommant énormément de RAM ?

Actuellement quand un des processus est tué par le kernel, systemd arrête le service.
Donc il pourrait être utile de configurer le service systemd avec OOMPolicy=continue.
S'il s'agit d'un processus fils, seuls les clients gérés par celui-ci seraient déconnectés, le serveur resterait fonctionnel.
Mais ça pourrait ne pas être pris en compte, cf https://github.com/systemd/systemd/issues/25376.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 07 juillet 2023 à 08:38:51
L'événement oom-killer s'est produit le 3 juillet, là où on voit un changement brutal de l'utilisation de la mémoire.

/tmp est en ramdisque de même que /var/log/apache2 (cela limite les écritures sur le SSD) mais je ne vois rien de particulier à ce moment-là.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 07 juillet 2023 à 09:45:36
C'est peut-etre un bug ou l'exploitation d'un bug. il est a jour ton Apache (2.4.57 a ce jour) ainsi que les autres composants utilisés (php,ssl,un mod particulier)?
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 07 juillet 2023 à 10:03:33
Oui, Ubuntu 22.04 LTS à jour et pas de composants externes ou particuliers.

Le serveur est par contre ouvert dur de très nombreux ports, pour permettre des tests de neutralité.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: kgersen le 07 juillet 2023 à 11:17:00
Oui, Ubuntu 22.04 LTS à jour et pas de composants externes ou particuliers.

si tu ne dépend que de Ubuntu pour les maj tu n'aura pas grand chose a jour...hormis les CVE importantes.

dixit https://packages.ubuntu.com/km/jammy/apache2
-> t'en donc en  " 2.4.52  : Released on December 20, 2021"  au niveau fonctionnalités/bugs non critiques.

et https://bugs.launchpad.net/ubuntu/+source/apache2/2.4.52-1ubuntu4.6 pour le dernier patch critiques/secu.

bon apres ce n'est peut-être pas un bug logiciel Apache ou Php.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: hwti le 08 juillet 2023 à 00:43:19
L'événement oom-killer s'est produit le 3 juillet, là où on voit un changement brutal de l'utilisation de la mémoire.

/tmp est en ramdisque de même que /var/log/apache2 (cela limite les écritures sur le SSD) mais je ne vois rien de particulier à ce moment-là.
Là ce qu'on voit c'est un pic pour "Apps", et la taille de shmem (les fichiers de test dans /tmp, qu'on pourrait réduire un peu).
Ce qu'il faudrait regarder, ce sont les logs kernel (via journalctl probablement), l'oom-killer donne un certain nombre d'informations sur l'occupation mémoire, en détaillant le RSS pour chaque processus.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: ouno le 07 octobre 2023 à 18:51:43
https://bouygues.testdebit.info/ toujours down ?

C'est dommage il était bien pratique ce serveur HTTP Cubic pour comparer avec BBR.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 08 octobre 2023 à 22:20:11
Désolé, toujours le même problème, que je n'ai que sur ce serveur.

C'est redémarré.
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: ouno le 08 octobre 2023 à 22:41:29
Pas de souci, merci !

Ce serveur a exactement la même conf que les autres ? C'est bizarre quand même que le problème n'arrive que sur celui-ci  ???
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: ouno le 10 octobre 2023 à 21:08:09
Pour info je crois que ça vient de retomber
Titre: Linux: Réaliser un test de débit descendant/montant avec CURL
Posté par: vivien le 10 octobre 2023 à 22:15:14
Relancé.