Débogage d'un taux de transfert lent depuis le serveur

9

J'essaie d'expliquer cela aussi simple mais documenté que possible. Ce n'est pas exclusif à ce serveur ou à mon FAI actuel . J'ai vu le même problème exact au fil des ans tout en étant avec différents FAI et en ayant mes serveurs avec différents fournisseurs (GoDaddy aux États-Unis, iWeb et GloboTech au Canada). La seule chose courante est le système d'exploitation Windows Server (2003 et 2008 r2). Mais regardons maintenant mon serveur actuel et mon FAI actuel uniquement.

Le problème :

J'obtiens des taux de transfert très lents entre mon poste de travail local et mon serveur dédié distant. Mon serveur est sur un port de 100 Mbps et mon poste de travail local est sur une connexion symétrique de 50 Mbps sur fibre optique.

Symptômes :

Le serveur et la station de travail obtiennent tous deux d'excellents résultats (très proches de leur vitesse de connexion) lors de tests sur speedtest.net sur différents serveurs et emplacements aux États-Unis et au Mexique. Si je télécharge de gros fichiers depuis, disons, Dropbox, vers mon serveur ou mon poste de travail, j'obtiens des taux de transfert de 10 Mbps et 5 Mbps respectivement sur une seule connexion, ce qui est correct en fonction de chaque vitesse de connexion de 100 Mbps et 50 Mbps respectivement.

Pourtant, si je transfère un fichier de mon serveur (via HTTP ou FTP) vers mon poste de travail, je ne suis même pas proche de la vitesse de 50 Mbps que je devrais obtenir (taux de transfert de 5 Mbps) mais j'obtiens plutôt quelque chose d'équivalent à 3 Mbps (Taux de transfert de 300 kbps).

J'essaie de comprendre pourquoi j'obtiens un taux de transfert aussi lent. Je ne sais pas comment le déboguer. Chaque fois que je soulève un problème avec les hébergeurs, ils me demandent des sorties Tracert et finalement le blâment sur un serveur au milieu. Mais cela ne semble pas être correct, si nous prenons en considération ce que j'ai dit au début: j'ai vu cette vitesse / problème exact tout en ayant mes serveurs avec GoDaddy, iWeb et GloboTech, et tout en étant moi-même avec différents FAI sur très différents types de services Internet . Cela ressemble vraiment à un paramètre fixe quelque part dans la zone du serveur.

Tests que j'ai effectués :

TEST DE RAPIDITÉ

Ce sont des tests de vitesse de speedtest.net qui ont été exécutés sur mon serveur dédié contre différents serveurs distants, y compris un serveur dans le centre de données de mon FAI à Mexico:

Canada : 94,64 Mbps pour le téléchargement et 94,87 pour le téléchargement http://www.speedtest.net/my-result/3470801975

San Jose, CA : 93,58 Mbps pour le téléchargement et 95,48 Mbps pour le téléchargement http://www.speedtest.net/my-result/3470805341

Mexico (serveur dans le datacanter de mon propre FAI) : 92,99 Mbps pour le téléchargement et 95,39 Mbps pour le téléchargement http://www.speedtest.net/my-result/3470810269

Si j'exécute ces tests sur les mêmes serveurs à partir de mon poste de travail local, j'obtiens également des vitesses proches de ma connexion à 50 Mbps.

TRACERT

Il s'agit d'une sortie Tracert récente exécutée depuis mon poste de travail vers mon serveur dédié:

 1    <1 ms    <1 ms    <1 ms  192.168.7.254
 2     2 ms     1 ms     1 ms  10.69.32.1
 3     *        3 ms     2 ms  10.5.50.174
 4     3 ms     2 ms     2 ms  10.5.50.173
 5     *        5 ms     3 ms  fixed-203-69-2.iusacell.net [189.203.69.2]
 6    32 ms    32 ms    32 ms  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
 7    33 ms    33 ms    33 ms  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
 8    33 ms    33 ms    33 ms  ae13.dal33.ip4.tinet.net [77.67.71.221]
 9    76 ms    76 ms   157 ms  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
10    72 ms    72 ms    72 ms  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
11    72 ms    72 ms    72 ms  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
12    72 ms    72 ms    73 ms  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
13    72 ms    72 ms    72 ms  ns1.marveldns.com [173.209.57.82]

IPERF

Il s'agit d'un test iperf exécuté en utilisant mon serveur dédié comme serveur et mon poste de travail comme client:

------------------------------------------------------------
Client connecting to ns1.marveldns.com, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.7.2 port 60339 connected with 173.209.57.82 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.3 sec  5.62 MBytes  4.59 Mbits/sec

CHEMINEMENT

Voici la sortie d'une recommandation pathping exécutée depuis mon poste de travail vers mon serveur dédié:

Tracing route to ns1.marveldns.com [173.209.57.82]
over a maximum of 30 hops:
  0  ws1 [192.168.7.2]
  1  192.168.7.254
  2  10.69.32.1
  3     *     10.5.50.174
  4  10.5.50.173
  5  fixed-203-69-2.iusacell.net [189.203.69.2]
  6  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
  7  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
  8  ae13.dal33.ip4.tinet.net [77.67.71.221]
  9  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
 10  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
 11  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
 12  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
 13  ns1.marveldns.com [173.209.57.82]

Computing statistics for 325 seconds...
            Source to Here   This Node/Link
Hop    RTT  Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           ws1 [192.168.7.2]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.7.254
                                0/ 100 =  0%   |
  2    1ms     0/ 100 =  0%     0/ 100 =  0%  10.69.32.1
                                0/ 100 =  0%   |
  3    3ms     0/ 100 =  0%     0/ 100 =  0%  10.5.50.174
                                0/ 100 =  0%   |
  4    2ms     0/ 100 =  0%     0/ 100 =  0%  10.5.50.173
                                0/ 100 =  0%   |
  5    4ms    20/ 100 = 20%    20/ 100 = 20%  fixed-203-69-2.iusacell.net [189.203.69.2]
                                0/ 100 =  0%   |
  6   34ms     0/ 100 =  0%     0/ 100 =  0%  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
                                0/ 100 =  0%   |
  7   34ms     0/ 100 =  0%     0/ 100 =  0%  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
                                0/ 100 =  0%   |
  8   33ms     0/ 100 =  0%     0/ 100 =  0%  ae13.dal33.ip4.tinet.net [77.67.71.221]
                                0/ 100 =  0%   |
  9   79ms     0/ 100 =  0%     0/ 100 =  0%  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
                                2/ 100 =  2%   |
 10   73ms    14/ 100 = 14%    12/ 100 = 12%  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
                                0/ 100 =  0%   |
 11   72ms     2/ 100 =  2%     0/ 100 =  0%  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
                                2/ 100 =  2%   |
 12   72ms    18/ 100 = 18%    14/ 100 = 14%  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
                                0/ 100 =  0%   |
 13   72ms     4/ 100 =  4%     0/ 100 =  0%  ns1.marveldns.com [173.209.57.82]

Trace complete.

Des choses que vous pouvez essayer par vous-même

Si vous voulez l'essayer, voici quelques éléments que j'ai configurés sur le serveur à des fins de test:

Gros fichier sur serveur HTTP

J'ai placé un fichier de 5 Go sur mon serveur qui peut être téléchargé via HTTP. Vous pouvez le trouver ici: http://www.marveldns.com/transfer_test/

Application Speedtest MINI

J'ai configuré un test "speedtest mini" sur mon serveur. Vous pouvez le visiter et voir quelle vitesse il indique que vous obtenez pour le téléchargement et le téléchargement sur mon serveur et vous-même. Vous pouvez le trouver ici: http://www.marveldns.com/speedtest/

Enfin :

Comme je l'ai déjà dit, j'essaie d'obtenir de l'aide pour comprendre le tout. Je ne suis pas expert en TCP / IP ou en réseau haut de gamme. Honnêtement, je ne sais même pas clairement comment utiliser les résultats de tracert, iperf ou pingpath pour pouvoir résoudre le problème, mais je les inclue car je le demande toujours lorsque je parle de ce problème.

Si ma question manque de quelque chose pour être mieux, s'il vous plaît ne vous contentez pas de voter en bas et faites-moi savoir ce qui ne va pas ou quoi d'autre je peux y ajouter pour obtenir de l'aide. Je vous remercie.

Francisco Zarabozo
la source
juste parce que je suis curieux, quelle vitesse avez-vous lorsque vous wget votre fichier sur localhost sur votre serveur dédié?
Brice
Salut Brice. J'obtiens quelque chose autour de 50 Mo / s (octets, pas bits), ce qui est à peu près la même vitesse que j'obtiens si je copie manuellement le fichier dans le même dossier sur le même disque directement dans l'Explorateur Windows (il est donc limité par la vitesse de le disque pendant qu'il lit et écrit sur lui-même).
Francisco Zarabozo
1
Selon Tracert, votre poste de travail se trouve sur un réseau assez important. Avez-vous essayé de demander à l'administrateur du réseau local s'il existait une sorte de Qos qui ralentirait les connexions?
Si vous lancez plusieurs transferts simultanément, la vitesse combinée atteint-elle près des 50 Mbit / s attendus? c'est à dire. Est-ce lent sur tout ou lent par connexion?
Grant
@Grant: Avec plusieurs connexions, il annonce jusqu'à 50 Mbps. La limite se produit par connexion.
Francisco Zarabozo

Réponses:

9

Le goulot d'étranglement que je vois lors de l'accès à cette URL est clairement dû à la taille de la fenêtre.

Lorsque j'essaie de télécharger à partir de votre serveur, j'obtiens 555 Ko / s. J'ai un temps aller-retour de 108 ms. En faisant le calcul, j'obtiens la taille de fenêtre suivante: 555 Ko / s * 108 ms = 59,94 Ko.

Tant que je le fais à partir d'un hôte dans un centre de données, j'obtiens un débit et un aller-retour très cohérents. De plus, si je lance deux téléchargements en parallèle, chacun obtient 555 Ko / s. C'est exactement les symptômes que vous verrez lorsque le goulot d'étranglement est la taille de la fenêtre.

Sans mise à l'échelle de la fenêtre, la fenêtre ne peut pas dépasser 64 Ko. Mais je vois que la mise à l'échelle des fenêtres doit être négociée, donc un débit plus élevé devrait être possible. Cela laisse deux hypothèses à étudier:

  • Quelque chose modifie l'option de mise à l'échelle de la fenêtre sur le chemin du client au serveur, ce qui fait penser au serveur que la fenêtre est mise à l'échelle par un facteur de 1.
  • Le serveur peut être configuré pour ne jamais utiliser plus de 60 Ko de fenêtre d'envoi sur chaque connexion.

Le premier est facile à vérifier si vous pouvez effectuer une capture de paquets sur le serveur. Il suffit de regarder l'option de mise à l'échelle sur les paquets SYN entrants pour savoir si un facteur de mise à l'échelle supérieur à un est reçu par le serveur. Je peux recommander d'utiliser Wireshark pour analyser le trafic.

La vérification de la deuxième hypothèse nécessite une certaine connaissance du système d'exploitation que vous utilisez. Il se trouve que vous avez choisi un système d'exploitation, qui m'est inconnu, pour que je ne puisse pas vous aider. Je ne peux donc que vous aider avec une expertise en réseautage.

kasperd
la source
Je ne suis pas sûr à 100%, mais la taille de la fenêtre n'est-elle pas affectée par la taille du tampon d'envoi et de réception du socket (options de socket SO_RVSBUF et SO_SNDBUF)? J'ai vu des incidents similaires où le tampon était trop petit (par exemple, 1 Ko) et le débit était très limité par rapport à 4 Ko ou 8 Ko).
Cameron Kerr
@CameronKerr Votre commentaire m'a incité à revoir la communication. Cette fois, j'ai testé depuis mon ordinateur portable (qui est sur le WiFi et obtient un débit inférieur). Ce que j'ai observé, c'est que j'obtiens 138 Ko / s avec un aller-retour de 105 ms. Cela signifie une taille de fenêtre effective de 14,5 Ko. La fenêtre de réception annoncée par mon ordinateur portable est passée à 679 << 7 (environ 85 Ko) avant que le débit ne se stabilise. Cela devrait exclure la possibilité que le facteur d'échelle soit simplement mis à zéro en transit et devrait exclure la possibilité que le débit soit limité par le tampon de réception de ma part.
kasperd
Un article pertinent pour Windows Server 2008 r2 peut être trouvé ici: andydavies.me/blog/2011/11/21/…
Francisco Zarabozo