Je ne comprends pas ce qui te dérange.
> Qui me ment ?
Personne, on a bien 2582904μs > 2578351μs > 1003254μs
Apache bufferise-t-il ce qui lui vient de plus loin avant de le renvoyer ou le renvoie-t-il au fil de l'eau ?
Il bufferise dans une certaine mesure. Le reverse-proxy n'est pas un switch ou un équipement réseau de niveau IP. Lorsqu'il reçoit une requête, il la traite, et il créer une NOUVELLE requête vers le serveur suivant. La bufferisation dépends de la version d'apache et du protocole HTTP utilisé pour chaque liaison (tu as 3 requêtes HTTP différentes). Regarde en particulier le mode chunked de HTTP/1.1. Si tu as un filtre de sortie, genre compression, ça augmente les besoins de bufferisation.
Le temps indiqué dans les logs indique-t-il :
- du début de la requête jusqu'à ce que le dernier octet soit renvoyé et la connexion clôturée ?
- du début de la requête jusqu'à ce que le premier octet soit renvoyé ?
Chaque serveur doit parser la requête qu'il reçoit, appliquer un certain nombre de règles, se connecter au serveur suivant, envoyer sa requête. Dans le pire des cas, il peut avoir un filtre sur la sortie, genre une compression, ou des entêtes à calculer, comme la taille de la réponse.
Si en amont de mes RPs le débit/latence est pourrave cela peut-il faire que le RP molassonne mon WS ?
Pas sur quelques Ko, parce que l'OS fait tampon, mais il est facile de montrer qu'a partir de quelques dizaines ou centaines de Ko, si le RP est bloqué sur une émission vers le navigateur, il ne va pas lire ce qui est arrivé du serveur (l'OS réduit la fenêtre TCP jusqu'à 0 si nécessaire), et toute la chaine ralentie.
Le test est facile à faire, gdb permet d'aller de syscall en syscall (commande "catch syscall" puis "continue" pour avancer) pour ralentir la lecture des paquets. Faire envoyer un gros fichier d'un nc à un autre sur le localhost. Un tcpdump montre bien que la fenêtre TCP tombe à 0, on constate aussi que l’émetteur est bloqué tant que le récepteur ne lit pas de données.
# Très cohérent
Posté par Sébastien Koechlin . En réponse au message Apache et ses logs. Évalué à 3.
Je ne comprends pas ce qui te dérange.
> Qui me ment ?
Personne, on a bien 2582904μs > 2578351μs > 1003254μs
Il bufferise dans une certaine mesure. Le reverse-proxy n'est pas un switch ou un équipement réseau de niveau IP. Lorsqu'il reçoit une requête, il la traite, et il créer une NOUVELLE requête vers le serveur suivant. La bufferisation dépends de la version d'apache et du protocole HTTP utilisé pour chaque liaison (tu as 3 requêtes HTTP différentes). Regarde en particulier le mode chunked de HTTP/1.1. Si tu as un filtre de sortie, genre compression, ça augmente les besoins de bufferisation.
C'est le temps depuis l'arrivée de la requête jusqu'au moment où toute la réponse est partie dans la couche réseau et que Apache est en train de logger la ligne. Ça se passe ligne 650 de http://svn.apache.org/viewvc/httpd/httpd/tags/2.2.20/modules/loggers/mod_log_config.c?revision=1163057&view=markup
Chaque serveur doit parser la requête qu'il reçoit, appliquer un certain nombre de règles, se connecter au serveur suivant, envoyer sa requête. Dans le pire des cas, il peut avoir un filtre sur la sortie, genre une compression, ou des entêtes à calculer, comme la taille de la réponse.
Pas sur quelques Ko, parce que l'OS fait tampon, mais il est facile de montrer qu'a partir de quelques dizaines ou centaines de Ko, si le RP est bloqué sur une émission vers le navigateur, il ne va pas lire ce qui est arrivé du serveur (l'OS réduit la fenêtre TCP jusqu'à 0 si nécessaire), et toute la chaine ralentie.
Le test est facile à faire, gdb permet d'aller de syscall en syscall (commande "catch syscall" puis "continue" pour avancer) pour ralentir la lecture des paquets. Faire envoyer un gros fichier d'un nc à un autre sur le localhost. Un tcpdump montre bien que la fenêtre TCP tombe à 0, on constate aussi que l’émetteur est bloqué tant que le récepteur ne lit pas de données.