Effet de la distance du serveur

13

J'ai un serveur Web en Irlande (Amazon AWS). Ce serveur apparaît vite d'Allemagne (ligne orange) mais lent des USA (ligne noire). La requête HTTP utilisée pour le test est la même.

entrez la description de l'image ici

Je pense que c'est normal. La distance entre l'Irlande et les États-Unis est plus grande que l'Allemagne vers l'Irlande, mais la différence semble trop élevée.

Y a-t-il d'autres raisons possibles, à part la distance au serveur?

networking domain-name-system performance ar099968
la source
7
Quel est votre graphique censé montrer? temps de parcours? temps total de demande? autre chose?
Peter Green
@PeterGreen http request time
ar099968

Réponses:

24

En supposant que le graphique est le temps de demande http, il me semble assez raisonnable.

Une requête http (en l'absence de keepalive, fastopen, etc.) nécessite normalement au moins deux allers-retours.

  • Le client envoie la synchronisation
  • Sever reçoit syn et envoie syn-ack
  • Le client reçoit syn-ack et envoie un accusé de réception et une demande.
  • Le serveur envoie une réponse.

La vitesse de la lumière dans la fibre est d'environ 2 * 10 ^ 8 mètres par seconde. Selon Google, la distance entre "l'Irlande et les États-Unis" est de 6 629 km *, ce qui se traduirait par un temps de trajet d'environ 66 ms.

Mais cela suppose qu'il n'y a pas de retards dans l'équipement et que la route de données suit le chemin le plus court possible. Les temps d'aller-retour pratiques sont généralement de 100 à 150 millisecondes entre un hôte en Europe et un hôte aux États-Unis. En tant que tel, un temps de requête http de ~ 250 ms est parfaitement normal.

Ce qui est un peu plus préoccupant, ce sont les pics du graphique, ils suggèrent une congestion du réseau quelque part entre le serveur et le client de test.

* Évidemment, cela dépend de quel point aux États-Unis et de quel point en Irlande, mais le point choisi par Google semble être quelque part au milieu des États-Unis et le graphique OP indique "us-mid".

Peter Green
la source
18

Une autre raison possible en plus de la distance du serveur?

Chemin emprunté par les paquets.

user9517
la source
6
... et tous les appareils intermédiaires.
EEAA
8
... et à quel point ils sont congestionnés
user9517
1
En quoi cela est-il pertinent pour la question posée ... c'est ce que c'est sûrement? Avez-vous envisagé d'utiliser un outil comme say mtr pour examiner les chemins empruntés et le timing de chaque saut?
user9517
13
Je vois ce genre de question tout le temps où je travaille, donnant de beaux graphiques qui ont tendance à donner l'impression que l'utilisateur sait de quoi il parle jusqu'à ce que vous lui demandiez quelles traces et contrôles de trafic il a faits et rien n'a été vérifié.
Julie Pelletier
4
@Julie oui, les graphiques n'ont pas de sens sans connaissance et compréhension.
user9517
9

La recherche sur Google pour les ping "us-mid"rendements Monitis.com et leur adresse IP à Dallas, qui ont également une adresse IP DE à Francfort. Depuis un serveur très bien connecté en France, j'ai 9 ms ping RTT vers le DE IP et 111 ms ping RTT vers le US-MID IP. Pour le temps de réponse HTTP, je m'attendrais à doubler cela plus le temps de réaction du serveur, pour des raisons disons peut-être 26 et 230. Ce n'est pas si différent de vos valeurs, étant donné qu'en Irlande, vous êtes probablement un peu plus loin sur le réseau -dans les deux endroits.

Acceptez ces valeurs comme normales et surveillez les écarts par rapport à celles-ci pour voir s'il y a des problèmes sur votre site ou avec votre FAI. À moins que vous ne dirigiez un service mondial qui est vraiment critique en termes de temps de réponse, il est inutile d'en faire plus. Si vous l'êtes, mettez des serveurs dans le monde entier ou (mieux) passez un contrat avec des hébergeurs spécialisés dans ce domaine.

Loi29
la source
-2

Voici une belle page de statistiques globales de ping: https://wondernetwork.com/pings Ajoutez simplement vos villes source et de destination.

Lorant Vajda
la source