Données obtenues par ping: s'agit-il d'un aller-retour ou d'un aller simple?

J'ai 2 serveurs, chacun dans deux emplacements distincts. J'ai besoin d'héberger une application sur l'un et le serveur de base de données sur l'autre.

À partir du serveur d'application, si je fais un ping sur le serveur de base de données, en moyenne, j'obtiens environ 30 ms.

Ma question est:

When I query the database from the app;

Est-ce que ça va prendre 30 ms + database_server_query_run_time

Ou;

Est-ce que ça va prendre 30 ms + database_server_query_run_time+ 30ms

Je voudrais comprendre cela s'il vous plaît.

networking ping latency Phil
la source

Réponses:

Cela prendra généralement plus que ces deux options.

Le ping mesure juste le temps entre le client, le serveur et vice-versa (rtt - temps aller-retour)

Habituellement, les bases de données utilisent TCP, vous devez donc d'abord envoyer un paquet SYN pour démarrer la négociation TCP (pour simplifier disons 15 ms * + temps cpu, puis vous recevez et SYN / ACK (15 ms + temps cpu), renvoyez un ACK et un demande (au moins 15 ms + temps processeur), puis le temps nécessaire à la base de données pour traiter la requête, puis le temps (15 ms + processeur) pour récupérer les données, et un peu plus pour acquitter, et fermer la connexion.

Bien sûr, cela ne compte pas l'authentification (nom d'utilisateur / mot de passe) à la base de données, et aucun cryptage (poignée de main SSL / DH ou tout ce qui est nécessaire).

* la moitié d'un temps aller-retour, en supposant que l'itinéraire aller-retour est symétrique (la moitié du temps pour y arriver, et la moitié pour revenir ... le temps de traitement du processeur pour la réponse ping est très court)

mulaz
la source

Le problème de la négociation à trois peut être rencontré avec les sessions TCP persistantes.

Michuelnik

@Michuelnik, pourriez-vous s'il vous plaît développer? J'aimerais vraiment comprendre tout cela et trouver le meilleur moyen de minimiser la latence pour interroger la base de données.

Phil

Malheureusement, la plupart des logiciels (au moins les applications Web) ne prennent pas en charge ceci: / Mais l'idée est, d'établir la connexion (une fois) à la base de données, et de maintenir la connexion en cours (ouverte), et de continuer à envoyer des requêtes / obtenir des réponses sur une seule, connexion constamment ouverte. Cela élimine le besoin de prises de contact TCP, d'authentification, etc. à chaque fois.

mulaz

mulaz, merci de m'avoir expliqué. Je vais travailler avec Python donc nous verrons comment ça se passe. ;-)

Phil

N'oubliez pas la taille de la demande et de la réponse. Par exemple, sur une liaison de 1 Mo / s, une charge utile de 100 Ko prendrait 100 ms supplémentaires à transporter.

Dustin Boswell

Le temps de ping est aller-retour. Si vous y réfléchissez - comment pourrait-il mesurer le temps à sens unique? Cela prendra donc 30 ms plus le temps de requête.

David Schwartz
la source

J'ajouterai simplement que cela va probablement prendre un peu plus de temps que les 30 secondes + le temps de requête. puisque Ping est ICMP et votre connexion DB est TCP, vous aurez également la configuration / prise de contact, et l'initiation de la connexion DB, etc.

Doon

@Doon: Ce qui pourrait être "évité" avec des connexions TCP / base de données persistantes

Michuelnik

@Michuelnik, pensez-vous que la connexion DB persistante est le chemin à parcourir ici? Cela causera-t-il d'autres problèmes?

Phil

@michuelnik, bien sûr. Je soulignais simplement que ce n'est pas aussi simple que RTT + Query. Il y a aussi des limites à la vitesse maximale, par session en raison de la latence, etc.)

Doon

@phil Dans la plupart des cas, les connexions de base de données persistantes sont avantageuses, si vous devez effectuer plusieurs requêtes. Si les requêtes sont dispersées / sporadiques, vous utilisez des ressources inutilement, mais si les requêtes arrivent tout le temps, etc., vous économiserez une quantité non négligeable de frais généraux en réutilisant la connexion existante au lieu d'en ouvrir une nouvelle à chaque demande.

Doon