Latence réseau: 100Mbit vs 1Gbit

11

J'ai un serveur Web avec une connexion actuelle de 100Mbit et mon fournisseur propose une mise à niveau vers 1Gbit. Je comprends que cela se réfère au débit, mais plus les paquets sont grands, plus ils peuvent être transmis rapidement, donc je m'attends à une légère diminution du temps de réponse (par exemple, ping). Quelqu'un a-t-il déjà évalué cela?

Exemple (serveur de 100 Mbits à 100 Mbits) avec une charge de 30 octets:

> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms

Exemple (serveur de 100 Mo à 100 Mo) avec une charge de 300 octets (ce qui est inférieur à MTU):

> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms

Donc de 30 à 300 moy. la latence augmente de 0,164 à 0,395 - je m'attends à ce que ce soit une augmentation plus lente pour une connexion de 1 gibt à 1 gbit. Je m'attendrais même à ce que 100 Mbits à 1 Gbit soit plus rapide, si la connexion se fait via un commutateur qui attend d'abord d'avoir reçu le paquet entier.

Mise à jour: Veuillez lire attentivement les commentaires des réponses! La connexion n'est pas saturée, et je ne pense pas que cette augmentation de vitesse importera aux humains pour une seule requête, mais il s'agit de nombreuses requêtes qui s'additionnent (Redis, Database, etc.).

Concernant la réponse de @LatinSuD :

> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms
Andreas Richter
la source
Il existe également un codage différent (10b / 12b?) Avec de nouvelles cartes et câbles Ethernet gbit, de sorte qu'il pourrait avoir% 25 de performances supplémentaires en plus de 10x (lorsqu'il est saturé) par rapport à 100Mbit peut-être?
huseyin tugrul buyukisik

Réponses:

15

La seule façon dont la latence chuterait sensiblement est si la liaison actuelle à 100 Mbits est saturée. S'il n'est pas saturé, vous ne remarquerez probablement aucun changement.

En outre, votre hypothèse selon laquelle la liaison 1 Gbit pourra prendre en charge des paquets plus volumineux est incorrecte. La taille maximale des paquets est déterminée par la MTU des différents appareils le long du chemin emprunté par le paquet - en commençant par la carte réseau de votre serveur, jusqu'à la MTU de l'ordinateur de votre client. Dans les applications LAN internes (lorsque vous contrôlez tous les périphériques le long du chemin), il est parfois possible d'augmenter le MTU, mais dans cette situation, vous êtes à peu près bloqué avec le MTU par défaut de 1500. Si vous envoyez des paquets plus grands que cela, ils finiront par être fragmentés, réduisant ainsi les performances.

EEAA
la source
2
"Appréciable" est le mot clé ici. Je viens de vérifier deux serveurs avec un matériel identique et une faible charge réseau, mais avec des vitesses Ethernet différentes. Le temps de ping moyen (local, avec la source de ping sur le même sous-réseau) est passé de 0,21 millisecondes à 0,17 millisecondes. Pinging les mêmes serveurs de la maison, chacun avait un temps de 53 millisecondes. Il y a bien trop de facteurs indépendants de la volonté de votre fournisseur pour en faire une mise à niveau intéressante.
Mike Renfro
1
+1 Techniquement, il y a une différence, mais elle est complètement inappréciable à moins que l'application particulière ne soit incroyablement sensible à la latence.
Chris S
Merci pour le test! De 0,21 à 0,17, c'est une amélioration de 20%, ce qui est formidable. Je ne suis pas concerné par le ping depuis la maison (50 ms) mais le temps que la demande reste chez le fournisseur. Nous avons peaufiné tous les traitements (CPU) et non-IO (RAM / Cache / etc.) Au maximum, alors je me demande maintenant combien la vitesse du réseau entre les serveurs ajoute à la latence totale. Par exemple, nous faisons ~ 20 demandes Redis pour une demande de serveur Web. @MikeRenfro: pouvez-vous faire le même test avec une taille de charge plus élevée? Le ping normal est de 30 octets, moy. Redis autour de 250. Je m'attendrais à ce que la différence s'accentue.
Andreas Richter
2
@Andreas; Je pense que vous avez totalement raté le point de ces commentaires. C'est une amélioration de 40 nanosecondes. Un montant qui est totalement imperceptible pour les êtres humains . Et ce n'est pas un nombre cumulatif, ce n'est pas comme si chaque requête prenait 40 nanosecondes de plus; c'est juste que le premier sera beaucoup plus rapide, donc le second sera aligné juste derrière de toute façon.
Chris S
1
@ChrisS: la question n'était pas sur la perceptibilité - c'était une question si quelqu'un le testait et Mike l'a fait. Ce n'est pas non plus 40 nano-secondes, c'est des micro-secondes , donc vous manquez le point par facteur 1000 ... bravo. Croyez-moi, je sais ce que je fais ... 20% serait suffisant pour justifier les coûts supplémentaires.
Andreas Richter
12

OUI le gbit a une latence plus faible, car:

  • le même nombre d'octets peut être transféré plus rapidement

Mais l'amélioration est appréciable que si le paquet (s) ont une certaine taille:

  • Paquet de 56 octets => pratiquement pas de transfert plus rapide
  • Paquet de 1000 octets => 20% de transfert plus rapide
  • Paquet (s) 20000 octets => 80% de transfert plus rapide

Donc, si vous avez une application qui est très sensible à la latence (4 ms contre 0,8 ms, aller-retour pour 20 Ko) et que vous avez besoin de transférer des paquets plus volumineux, le passage de 100 Mo au Gbit peut vous permettre de réduire la latence, même si vous utilisez beaucoup moins que les 100 Mbits / s en moyenne (= le lien n'est pas saturé en permanence).

Serveur (100 Mbits) -> Switch (gbit) -> Serveur (100 Mbits):

size: 56 :: rtt min/avg/max/mdev = 0.124/0.176/0.627/0.052 ms
size: 100 :: rtt min/avg/max/mdev = 0.131/0.380/1.165/0.073 ms
size: 300 :: rtt min/avg/max/mdev = 0.311/0.463/2.387/0.115 ms
size: 800 :: rtt min/avg/max/mdev = 0.511/0.665/1.012/0.055 ms
size: 1000 :: rtt min/avg/max/mdev = 0.560/0.747/1.393/0.058 ms
size: 1200 :: rtt min/avg/max/mdev = 0.640/0.830/2.478/0.104 ms
size: 1492 :: rtt min/avg/max/mdev = 0.717/0.782/1.514/0.055 ms
size: 1800 :: rtt min/avg/max/mdev = 0.831/0.953/1.363/0.055 ms
size: 5000 :: rtt min/avg/max/mdev = 1.352/1.458/2.269/0.073 ms
size: 20000 :: rtt min/avg/max/mdev = 3.856/3.974/5.058/0.123 ms

Serveur (gbit) -> Commutateur (gbit) -> Serveur (gbit):

size: 56 :: rtt min/avg/max/mdev = 0.073/0.144/0.267/0.038 ms
size: 100 :: rtt min/avg/max/mdev = 0.129/0.501/0.630/0.074 ms
size: 300 :: rtt min/avg/max/mdev = 0.185/0.514/0.650/0.072 ms
size: 800 :: rtt min/avg/max/mdev = 0.201/0.583/0.792/0.079 ms
size: 1000 :: rtt min/avg/max/mdev = 0.204/0.609/0.748/0.078 ms
size: 1200 :: rtt min/avg/max/mdev = 0.220/0.621/0.746/0.080 ms
size: 1492 :: rtt min/avg/max/mdev = 0.256/0.343/0.487/0.043 ms
size: 1800 :: rtt min/avg/max/mdev = 0.311/0.672/0.815/0.079 ms
size: 5000 :: rtt min/avg/max/mdev = 0.347/0.556/0.803/0.048 ms
size: 20000 :: rtt min/avg/max/mdev = 0.620/0.813/1.222/0.122 ms

= en moyenne sur plusieurs serveurs réduction de latence de 80% pour un ping de 20 Ko

(Si un seul des liens est le gbit, vous aurez toujours une réduction de latence de 5% pour un ping de 20 Ko.)

Andreas Richter
la source
1
La plupart des équipements réseau étant stockés et transférés, un paquet doit être entièrement reçu par un commutateur / routeur avant d'être transmis. Des connexions plus rapides réduisent ce temps, ce qui réduit également la latence (tant que la connexion n'obtient pas la vitesse de plusieurs liaisons parallèles).
Brian
1
En raison de l'explication, cette réponse est de loin la meilleure de la page. Les autres semblent vouloir expliquer ce fait en supposant un cas particulier - les performances du réseau sur une longue distance / beaucoup de commutateurs. C'est important à prendre en compte, en particulier compte tenu de la préoccupation de l'OP (serveur Web), mais cette réponse montre également la différence de vitesse de commutation possible en un seul saut.
Tyler
3

Je pense que vous avez une idée fausse fondamentale sur la latence de la bande passante et la "vitesse". La vitesse est fonction de la bande passante et de la latence. Par exemple, considérez un envoi de données sur des DVD expédiés à travers le pays en 3 jours pour arriver. Comparez cela à l'envoi des données sur Internet. Internet a une connexion à latence beaucoup plus faible, mais pour faire correspondre la «vitesse» de la connexion à l'envoi, vous devez avoir une réception à 9,6 Mo par seconde ( exemple de référence de cette source ).

Dans votre cas, la mise à niveau vers une bande passante plus élevée vous permettrait de servir plus d'utilisateurs simultanés mais pas d'améliorer la latence pour un utilisateur individuel.

Jim B
la source
C'est incorrect - comparez simplement le ping avec une charge utile différente qui est inférieure à la MTU actuelle: serveur ping -i0.05 -c200 -s30 vs serveur ping -i0.05 -c200 -s300 ... Ou en parlant dans votre exemple: le un camion avec 1 million de DVD roulerait plus lentement, car il est plus lourd que celui avec 1 DVD.
Andreas Richter
2
@andreas ping time n'est pas toute l'histoire - prenons donc pour argument que les paquets inférieurs au MTU arrivent plus rapidement que les paquets au MTU complet. la différence est que vous n'avez pas toutes les données que le 1 paquet a à pleine mtu dans le même temps que les 2 paquets mettent pour arriver. La latence est le temps mis pour que toutes les données arrivent. pour revenir à l'analogie du camion, même s'il faut un camion avec 1 Cd pour arriver en deux fois moins de temps que le camion transportant 500 cd il faut quand même 500 camions pour livrer les données (750 jours vs 3).
Jim B
@JimB: oui, comme mentionné, ma question n'était pas sur la taille de la charge, mais sur la vitesse: le camion complet a besoin de 10 heures pour être scanné par les douanes, le petit seulement 1 heure. 100 Mbits / s signifie également qu'un paquet de 100 bits a besoin d'un minimum théorique de 0,000954ms et un paquet de 1000bit d'un minimum théorique de 0,00954ms. Bien sûr, le temps de traitement / etc. sur la carte réseau / commutateur / etc. faire un morceau plus élevé de toute la latence, mais je m'attendrais également à ce que ce soit plus rapide dans un commutateur 1 Gbit, etc. Veuillez voir le commentaire de @MikeRenfro, il l'a effectivement testé et est venu à une augmentation de 20%.
Andreas Richter
@andreas - 20% sur le même sous-réseau, ce qui n'est pas pertinent pour votre question
Jim B
1
@andreas 20% d'un ping inférieur à la milliseconde est toujours un ping inférieur à la milliseconde. Même 150% d'un ping inférieur à la milliseconde, comme dans vos tests, n'auront pas d'importance dans le monde réel. Avez-vous vraiment une application où il importe que vos données soient arrivées en 0,0003 secondes au lieu de 0,0002 secondes ?
Shane Madden
2

Vous regardez le monde à travers un trou d'épingle. Un test valide des différences de latence à différentes vitesses serait entre deux cartes réseau identiques connectées avec un câble d'interconnexion. Définissez les vitesses de calcul NIC de 10 Mo, 100 Mo et 1000 Mo. Cela montrera qu'il n'y a pratiquement pas de différence de latence aux différentes vitesses. Tous les paquets voyagent à la même vitesse de connexion quelle que soit la bande passante maximale utilisée. Une fois que vous avez ajouté des commutateurs avec le stockage et la mise en cache avant, tout change. Le test de latence via un commutateur doit être effectué avec seulement deux connexions au commutateur. Tout autre trafic peut affecter la latence de votre test. Même alors, le commutateur peut survoler les journaux, ajuster les compteurs de type de paquets, mettre à jour l'horloge interne, etc. Tout peut affecter la latence.

Oui, le passage de 100 Mo à 1 Go peut être plus rapide (latence plus faible) en raison de changements matériels, d'une carte réseau différente, d'un commutateur différent, d'un pilote différent. J'ai vu des changements plus importants dans la latence ping des différences de pilotes que tout autre changement; bande passante, commutateurs, cartes réseau de déchargement, etc.

Le commutateur serait le prochain changement le plus important avec une coupure beaucoup plus rapide que le stockage et le transfert pour les tests de transmission unique. Cependant, un commutateur de stockage et de transfert bien conçu peut dépasser le commutateur de coupure dans les performances globales sous une charge élevée. Au début du gigabit, j'ai vu des commutateurs de fond de panier haute performance de 10 Mo avec une latence plus faible que les commutateurs gigabit bon marché.

Les tests Ping ne sont pratiquement pas pertinents pour l'analyse des performances lors de l'utilisation d'Internet. Ce sont des tests rapides pour avoir une idée approximative de ce qui se passe sur le transport au moment du test. Les tests de performances de production sont beaucoup plus compliqués qu'un simple ping. Les commutateurs hautes performances sont des ordinateurs et sous une charge élevée se comportent différemment - changement de latence.

Le fait d'avoir une carte réseau plus lente, ou une carte réseau définie sur une vitesse plus lente, pourrait en fait aider un serveur avec des rafales simultanées en limitant l'entrée au serveur à l'aide du cache des commutateurs. Une seule retransmission peut annuler toute diminution de latence. Habituellement, les niveaux de trafic à charge moyenne à élevée sont importants, pas les tests de ping uniques. Par exemple, Old Sun Ultrasparc lent (latence plus élevée pour un seul ping) surpasse le nouveau bureau gigabit bon marché utilisé comme serveur de développement sous une charge de bande passante de 70% à 100 Mo. Le bureau a une carte réseau gb plus rapide, une connexion gb-gb plus rapide, une mémoire plus rapide, plus de mémoire, un disque plus rapide et un processeur plus rapide, mais il ne fonctionne pas aussi bien que le matériel / logiciel de classe de serveur réglé. Cela ne veut pas dire qu'un serveur réglé actuel exécutant gb-gb n'est pas plus rapide que l'ancien matériel, même capable de gérer des charges de débit plus importantes. Il y a juste plus de complexité à la question "

Découvrez si votre fournisseur utilise différents commutateurs pour les connexions 100 Mo contre 1 Go. S'ils utilisent le même fond de panier de commutation que je ne paierais l'augmentation que si les niveaux de trafic dépassaient la bande passante inférieure. Sinon, vous pouvez constater qu'en peu de temps, de nombreux autres utilisateurs passeront au gigabit et que les quelques utilisateurs restants sur l'ancien commutateur auront désormais des performances plus élevées - une latence plus faible, lors de charges élevées sur le commutateur (charge globale du commutateur, pas seulement sur vos serveurs) ).

Exemple de pommes et d'oranges: le FAI local a fourni un nouveau commutateur pour les services groupés, DSL et téléphone. Au départ, les utilisateurs ont constaté une augmentation des performances. Le système a été survendu. Désormais, les utilisateurs qui restent sur l'ancien commutateur ont des performances cohérentes plus élevées. Tard dans la nuit, les utilisateurs du nouveau système sont plus rapides. Le soir, sous forte charge, les anciens clients de commutation surpassent clairement le nouveau système surchargé.

Une latence plus faible n'est pas toujours corrélée à une livraison plus rapide. Vous mentionnez MySQl dans les 20 demandes de diffusion d'une seule page. Ce trafic ne doit pas être sur la même carte réseau que les demandes de page. Le déplacement de tout le trafic interne vers un réseau interne réduira les collisions et le nombre total de paquets sur la carte réseau sortante et fournira des gains plus importants que le gain de latence de 0,04 ms d'un seul paquet. Réduisez le nombre de demandes par page pour réduire la latence de chargement des pages. Compressez les pages, html, css, javascript, images pour diminuer les temps de chargement des pages. Ces trois changements donneront des gains globaux plus importants en cours que le paiement de la bande passante non utilisée pour obtenir une réduction de latence de 0,04 ms. Le ping doit s'exécuter 24 heures et être moyenné pour voir le changement de latence réel. Les commutateurs intelligents font maintenant une limitation adaptative de type RTSP avec de petites augmentations de bande passante initiale et de gros transferts limités. En fonction de la taille de vos pages (graphiques, grand html / css / javascript), vous pouvez voir des latences de connexion / bande passante initiales beaucoup plus faibles / supérieures qu'une grande page ou des transferts de page entière. Si une partie de votre page est en streaming, vous pouvez voir des performances radicalement différentes entre la page et le flux.

Joe
la source
Merci pour toutes les excellentes contributions: 1.) C'est le même commutateur, 2.) Un deuxième NIC pour les sons internes / externes résonnables et mérite un essai - même si par exemple MySQL / etc. sont tous bidirectionnels, donc les collisions seraient "seulement" réduites de moitié, 3.) Un test dans le monde réel est préférable à seulement Nic-Nic, Mike l'a fait avec un sous-réseau et a obtenu ce que vous attendiez. matériel: "56 octets = 19% d'amélioration, 200 octets = 27%, 1 000 octets = 59%! Donc, plus le paquet est important, plus il est important. Et le gigabit n'a augmenté que de 0,17 ms (56 octets) à 0,23 ms (1 000 octets) ) => 35%, tandis que 100 Mbit est passé de 0,21 à 0,56 => 166% ".
Andreas Richter
1

Supposons que les paquets de 300 octets (si vous les utilisez -s 300soient en fait plus gros à cause des en-têtes).

300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms

0,024 ms est approximativement le temps réel requis pour envoyer la trame (sans compter le temps d'accès moyen ni les en-têtes).

Dans une séquence de ping-pong, cela prendrait deux fois ce temps (0,048 ms), plus le temps nécessaire au système d'exploitation pour traiter la requête.

Cela signifie pour moi que votre latence est causée par 90% de plusieurs facteurs de surcharge. Je ne sais pas si vous verrez beaucoup de différence avec Gb. Une différence probablement inférieure à 1 ms ne sera pas perceptible sur un serveur Web.

Quoi qu'il en soit, pourriez-vous essayer avec un très gros paquet comme 1400 octets?

LatinSuD
la source
Quelqu'un a déjà exécuté les chiffres pour un serveur particulier et la différence est revenue à 40 nanosecondes. Votre estimation approximative est 25 fois trop grande.
Chris S
@LatinSuD: merci pour l'approche constructive et ne blâmez pas que je ne sais pas ce que je fais. Je posterai les résultats dans la vraie question puisque je peux y faire du formatage. Mais au fait. Je m'attendrais également à ce que les frais généraux de 90% aient une augmentation de la vitesse , car les processeurs des cartes réseau, etc. sont également plus rapides pour GBit (espérons-le). @ChrisS: micro-secondes et je ne comprends pas ce que vous voulez dire avec le 25.
Andreas Richter
Mes excuses pour avoir mélangé micro et nano; en tout cas c'est imperceptible. LatinSuD a estimé une différence de 1 milliseconde entière, soit 25 fois plus que les 40 microsecondes trouvées par Mike.
Chris S
@ChrisS: pas de soucis. Le 0,04 ms était pour un ping de 38 octets, si notre paquet serveur-serveur moyen est d'environ 300 octets, la différence pourrait être de 0,4 ms. Si nous faisons maintenant 20 demandes pour un serveur Web requis (Redis, MySQL, etc.), cela entraînerait une augmentation de la vitesse de 8 ms qui serait une augmentation de 10% de la vitesse pour les demandes Web actuelles et justifierait totalement les coûts supplémentaires. Je n'ai tout simplement pas les ressources ici pour exécuter les tests moi-même, mais croyez-moi, même s'il n'est pas perceptible par les humains, il peut toujours être pertinent. Comme l'électricité ou Dieu.
Andreas Richter
1
@Andreas, je doute fortement qu'il évolue comme ça; à la fois un paquet 10x plus grand étant 10 fois moins de latence et 20x plus de paquets 20 fois plus rapide. Si cela se produit, c'est une réduction de 10% des frais généraux du réseau, vous devez toujours tenir compte du temps passé dans l'application, qui est probablement de un à plusieurs ordres de grandeur plus long que le composant de latence du réseau. J'espère que ça marche bien pour vous en tout cas.
Chris S
1

Cela dépend du type de commutateur auquel vous vous connectez. Sur certains fournisseurs (comme Crisco ... je veux dire Cisco), les paquets ICMP reviendront au CPU ( gag ).

Vous pouvez trouver un meilleur test serait d'effectuer un test d'hôte à hôte en utilisant une liaison 100 Mbps et 1 Gbps (c'est-à-dire pas un test d'hôte à commutateur ou d'hôte à routeur).

À la fin de la journée, la latence va se résumer au taux de transfert sur le commutateur et aux détails de l'architecture du commutateur (où les ASIC sont placés sur la carte, comment le verrouillage est géré entre les linecards, etc.). Bonne chance avec vos tests.

Sean
la source
Merci, je me réfère uniquement aux tests Host-Switch-Host et je ne comprends pas tous les commutateurs internes. J'aimerais simplement voir, si quelqu'un a déjà évalué: Host- (100mbit) -Switch- (100mbit) -Host, Host- (100mbit) -Switch- (1gbit) -Host and Host- (1gbit) -Switch- (1gbit ) -Latence de l'hôte pour différentes tailles de paquets. Si personne ne l'a fait, je le ferai et afficherai la réponse ici.
Andreas Richter
1
J'avais l'habitude de revendre du matériel de commutation. Il suffit de dire que vos résultats me suggèrent que vous êtes connecté à un commutateur Cisco. Il existe d'autres alternatives qui offrent des latences plus faibles. Comme vous l'avez souligné à juste titre, plus de bande passante ne se traduit pas par des latences plus faibles (Comcast est le principal coupable de rendre les gens stupides à cet égard). Étant donné que vous êtes dans un environnement hébergé, vous êtes probablement coincé avec leur matériel (et puisque dans un environnement hébergé, les quelques microsecondes supplémentaires ne sont pas vraiment cruciaux). Montrez-moi des millions de pps à l'état d'équilibre et je serai intéressé à fournir plus de détails. :)
Sean