Auteur Sujet: Algo de contrôle de la congestion TCP: BBR (Lu 38626 fois)

kgersen · « **Réponse #84 le:** 13 mars 2023 à 19:34:31 »

aucune idée, c'est quoi ton script d'upload deja ?

vivien · « **Réponse #85 le:** 13 mars 2023 à 19:44:24 »

Si c'est https://bouygues.testdebit.info/ul/ qui est utilisé, derrière c'est :

<!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>

Par contre, j'ai aussi un script utilisé par 5GMark et les outils de test de débit de QoSi by MOZARK :

https://bouygues.testdebit.info/ul/upload.php
<?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);
}

?>

kgersen · « **Réponse #86 le:** 13 mars 2023 à 22:51:36 »

hum curieux. a priori ces 2 scripts n'utilisent pas de fichiers temporaires dans /tmp.
regarde avec les dates&heures des fichiers et le log apache pour voir a quelles requêtes ils correspondent.
ils font quelles tailles ces fichiers phpxxxx et y'a quoi dedans ?

en general les fichiers dans /tmp sont supprimés quand un script se termine sauf si y'a un gros crash du script. surement aussi visible quelque part dans les logs.

Optix · « **Réponse #87 le:** 13 mars 2023 à 23:26:55 »

Citation de: vivien le 13 mars 2023 à 19:30:02

Les deux serveurs (paris / bouygues) sont chargés à environ 2 Gb/s (c'est assez stable dans le temps).

Par contre bouygues.testdebit.info avait sont /tmp de saturés.

Comment cela se fait que les fichiers uploadés ne sont pas supprimés ?

$ ls /tmp
ntpdate.log php62e8Di phpAJAZNr phpda9VPz phpfuqtr3 phpIfKMyD phpLjaBD0 phpo5qFgg phpPTLpNl phpsimq66 phpvoN6Rx phpYL2UxD
...

Soit :
- ton script est arrêté brutalement ou n'arrive pas à aller jusqu'au bout
- ton script ne fait jamais appel à "move_uploaded_file"; et donc les fichiers temporaires demeurent

kgersen · « **Réponse #88 le:** 14 mars 2023 à 00:26:38 »

Citation de: Optix le 13 mars 2023 à 23:26:55

- ton script ne fait jamais appel à "move_uploaded_file"; et donc les fichiers temporaires demeurent

non car

Citer

The file will be deleted from the temporary directory at the end of the request if it has not been moved away or renamed.

source: https://www.php.net/manual/en/features.file-upload.post-method.php

j'ai testé sur un serveur php de test,on voit bien le fichier temporaire (il suffit d'ajouter print_r($_FILES); dans le script pour voir le fichier temporaire). Le fichier temporaire est bien supprimer juste après la fin du script.

C'est donc surement un crash qui laisse les fichier temporaires.

@vivien tu peux monitorer /tmp avec cette commande:

Code: [Sélectionner]

inotifywait --monitor --timefmt "%a, %d %b %Y %T %z" --format "%T %e %w%f" --event move,create,delete ./tmp
(il faut installer inotifywait avec sudo apt install inotify-tools)

puis faire quelques tests upload, tu verra les évènements de création/suppression des fichiers temporaires.

Optix · « **Réponse #89 le:** 14 mars 2023 à 08:56:50 »

Citation de: kgersen le 14 mars 2023 à 00:26:38

non carsource: https://www.php.net/manual/en/features.file-upload.post-method.php

j'ai testé sur un serveur php de test,on voit bien le fichier temporaire (il suffit d'ajouter print_r($_FILES); dans le script pour voir le fichier temporaire). Le fichier temporaire est bien supprimer juste après la fin du script.

C'est donc surement un crash qui laisse les fichier temporaires.

Ok my bad.

Un max_execution_time trop court ou un timer côté php-fpm qui n'attend pas assez longtemps ? Là pareil, il faut voir dans les logs d'erreurs.

vivien · « **Réponse #90 le:** 14 mars 2023 à 09:27:46 »

J'ai regardé, la plupart des fichiers dans /tmp sont bien supprimés.

Y compris pour PHP.

Le problème, c'est que depuis hier, il y a environ 40 fichiers php qui n'ont pas été supprimés sans que je comprenne pourquoi.

Upload plus long que le timer coté php-fpm ?

# inotifywait --monitor --timefmt "%a, %d %b %Y %T %z" --format "%T %e %w%f" --event move,create,delete /tmp Setting up watches. Watches established. Tue, 14 Mar 2023 09:12:02 +0100 CREATE /tmp/iperf3.x590kv Tue, 14 Mar 2023 09:12:02 +0100 DELETE /tmp/iperf3.x590kv Tue, 14 Mar 2023 09:12:15 +0100 CREATE /tmp/iperf3.vTgFuV Tue, 14 Mar 2023 09:12:15 +0100 DELETE /tmp/iperf3.vTgFuV Tue, 14 Mar 2023 09:12:28 +0100 CREATE /tmp/php2X2YtW Tue, 14 Mar 2023 09:12:43 +0100 DELETE /tmp/php2X2YtW Tue, 14 Mar 2023 09:12:47 +0100 CREATE /tmp/phptWyPv5 Tue, 14 Mar 2023 09:13:07 +0100 CREATE /tmp/iperf3.gk2cGK Tue, 14 Mar 2023 09:13:07 +0100 DELETE /tmp/iperf3.gk2cGK Tue, 14 Mar 2023 09:13:13 +0100 CREATE /tmp/iperf3.X7U385 Tue, 14 Mar 2023 09:13:13 +0100 DELETE /tmp/iperf3.X7U385 Tue, 14 Mar 2023 09:13:14 +0100 DELETE /tmp/phptWyPv5

kgersen · « **Réponse #91 le:** 14 mars 2023 à 11:32:12 »

Citation de: vivien le 14 mars 2023 à 09:27:46

Upload plus long que le timer coté php-fpm ?

je doute quand même que ce ne soit pas géré...

Regarde tes logs apache2 pour voir quelle(s) requête(s) correspondent aux fichiers non supprimés.

vivien · « **Réponse #92 le:** 14 mars 2023 à 11:40:48 »

Tu vois ca comment ?

Code: [Sélectionner]

188.23.188.xx 54068 443 [14/Mar/2023:11:38:30 +0100] "POST https://ipv4.bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
92.219.47.xx 51820 443 [14/Mar/2023:11:38:31 +0100] "POST https://ipv4.bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
84.174.238.xx 38696 443 [14/Mar/2023:11:38:39 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109682 "-" "-"
77.21.236.xx 61511 443 [14/Mar/2023:11:38:44 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109767 "-" "-"
87.79.54.xx 62600 443 [14/Mar/2023:11:38:50 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
84.73.206.xx 57600 443 [14/Mar/2023:11:38:54 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109719 "-" "-"
77.57.172.xx 49258 443 [14/Mar/2023:11:39:06 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109682 "-" "-"
78.134.75.xx 36768 443 [14/Mar/2023:11:39:04 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
80.123.131.xx 55845 443 [14/Mar/2023:11:39:12 +0100] "POST https://ipv4.bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
188.61.59.xx 36186 443 [14/Mar/2023:11:39:14 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
93.220.190.xx 46044 443 [14/Mar/2023:11:39:21 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109767 "-" "-"

Optix · « **Réponse #93 le:** 14 mars 2023 à 11:55:37 »

Vu que c'est php-fpm, faut voir les logs à lui, vu que c'est lui qui prend la décision de timeout.

Mais oui, je mets une pièce sur un upload plus long que le timer.

vivien · « **Réponse #94 le:** 14 mars 2023 à 12:24:03 »

J'ai pas logué plus avec php-fpm, je vais lui demander d'être plus verbeux

Code: [Sélectionner]

[14-Mar-2023 11:33:48] WARNING: [pool www] child 82480, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (77.298450 sec), terminating
[14-Mar-2023 11:33:48] WARNING: [pool www] child 82480 exited on signal 15 (SIGTERM) after 2720.151385 seconds from start
[14-Mar-2023 11:33:48] NOTICE: [pool www] child 86218 started
[14-Mar-2023 11:48:28] WARNING: [pool www] child 76996, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (62.555015 sec), terminating
[14-Mar-2023 11:48:28] WARNING: [pool www] child 76996 exited on signal 15 (SIGTERM) after 8040.446160 seconds from start
[14-Mar-2023 11:48:28] NOTICE: [pool www] child 87441 started
[14-Mar-2023 11:50:08] WARNING: [pool www] child 79122, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (78.547338 sec), terminating
[14-Mar-2023 11:50:08] WARNING: [pool www] child 79122 exited on signal 15 (SIGTERM) after 6540.359027 seconds from start
[14-Mar-2023 11:50:08] NOTICE: [pool www] child 87581 started
[14-Mar-2023 11:50:48] WARNING: [pool www] child 86218, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (65.054672 sec), terminating
[14-Mar-2023 11:50:48] WARNING: [pool www] child 86218 exited on signal 15 (SIGTERM) after 1020.051003 seconds from start
[14-Mar-2023 11:50:48] NOTICE: [pool www] child 87724 started
[14-Mar-2023 12:08:09] WARNING: [pool www] child 75415, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (68.571061 sec), terminating
[14-Mar-2023 12:08:09] WARNING: [pool www] child 75415 exited on signal 15 (SIGTERM) after 10640.591859 seconds from start
[14-Mar-2023 12:08:09] NOTICE: [pool www] child 88822 started
[14-Mar-2023 12:21:49] WARNING: [pool www] child 75416, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (77.550853 sec), terminating
[14-Mar-2023 12:21:49] WARNING: [pool www] child 75416 exited on signal 15 (SIGTERM) after 11460.637476 seconds from start

ouno · « **Réponse #95 le:** 14 mars 2023 à 17:24:16 »

Citation de: kgersen le 13 mars 2023 à 17:34:52

J'avais fait des tests la semaine derniere avec NSpeed et 2 machines :
- une linux sous BBR qui sert a saturer la connexion en sortie
- une sous Windows Insiders canal Dev ou je changeait entre CUBIC et BBR2

bizarrement les résultats étaient en faveur de CUBIC... (peut-etre que BBR2 est plus "faible" que CUBIC fasse a BBR ?)

sur plusieurs tests, ca oscille entre 180 et 250 Mbps.
avec CUBIC cela a oscille entre 360Mbs et 600Mbps.

L'ideal serait d'avoir 500Mbps , partage équitable de la ligne (qui fait 1Gbps et qu'on obtient bien quand une seule machine fait l'upload).

Quand on met l'autre machine en CUBIC on obtient a peu près le même résultat entre CUBIC et BBR2 coté Windows. Entre 400 Mbps et 500 Mbps ce qui semble normal.

J'ai fait des tests de ce genre ici sauf que je m'intéresse au cas où une nouvelle connexion entre en concurrence avec une connexion existante qui a déjà atteint le max de la bande passante disponible, alors que toi si j'ai bien compris tu lances les deux simultanément.