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
la source
Réponses:
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.
la source
OUI le gbit a une latence plus faible, car:
Mais l'amélioration est appréciable que si le paquet (s) ont une certaine taille:
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):
Serveur (gbit) -> Commutateur (gbit) -> Serveur (gbit):
= 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.)
la source
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.
la source
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.
la source
Supposons que les paquets de 300 octets (si vous les utilisez
-s 300soient en fait plus gros à cause des en-têtes).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?
la source
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.
la source