Datos obtenidos del ping: ¿es ida y vuelta o ida?

Tengo 2 servidores, cada uno en dos ubicaciones separadas. Necesito alojar una aplicación en uno y el servidor de bases de datos en el otro.

Desde el servidor de aplicaciones, si hago ping al servidor de la base de datos, en promedio obtengo unos 30 ms.

Mi pregunta es:

When I query the database from the app;

Va a tomar 30 ms + database_server_query_run_time

¿Tardará más de 30 ms + database_server_query_run_time30 ms?

Me gustaría entender esto por favor.

networking ping latency

— Phil
fuente

Respuestas:

Por lo general, tomará más de esas dos opciones.

Ping mide solo el tiempo del cliente al servidor y viceversa (rtt - tiempo de ida y vuelta)

Por lo general, las bases de datos usan TCP, por lo que primero debe enviar un paquete SYN para iniciar el protocolo de enlace TCP (para simplificar, digamos 15 ms * + tiempo de CPU, luego recibe y SYN / ACK (15 ms + tiempo de CPU), devuelve un ACK y un solicitud (al menos 15 ms + tiempo de CPU), luego el tiempo para que el DB procese la consulta, y luego el tiempo (15 ms + CPU) para recuperar los datos, y un poco más para confirmar, y cerrar la conexión.

Por supuesto, esto no cuenta la autenticación (nombre de usuario / contraseña) a la base de datos, y no hay cifrado (ssl handshakes / DH o lo que sea necesario).

* la mitad de un tiempo de ida y vuelta, suponiendo que la ruta de ida y vuelta sea simétrica (la mitad del tiempo para llegar allí y la otra mitad para regresar ... el tiempo de procesamiento de la CPU para la respuesta de ping es muy corto)

— mulaz
fuente

El problema del apretón de manos de tres vías podría encontrarse con sesiones TCP persistentes.

— Michuelnik

@Michuelnik, ¿podría explicarlo? Realmente me gustaría entender todo esto y encontrar la mejor manera de minimizar la latencia para consultar la base de datos.

— Phil

Lamentablemente, la mayoría del software (al menos aplicaciones web) no admite esto: / Pero la idea es establecer la conexión (una vez) a la base de datos, y mantener la conexión en funcionamiento (abierta), y simplemente seguir enviando consultas / recibiendo respuestas a través de una, Conexión constantemente abierta. Esto elimina la necesidad de apretones de manos tcp, autenticación, etc. cada vez.

— mulaz

mulaz, gracias por explicarlo. Trabajaré con Python, así que veremos cómo funciona. ;-)

— Phil

No olvide el tamaño de la solicitud y la respuesta. Por ejemplo, a través de un enlace de 1 MB / seg, una carga útil de 100 KB tardaría 100 ms adicionales en transportarse.

— Dustin Boswell

El tiempo de ping es de ida y vuelta. Si lo piensa, ¿cómo podría medir el tiempo de ida? Por lo tanto, tardará 30 ms más el tiempo de consulta.

— David Schwartz
fuente

Solo agregaré que probablemente tomará un poco más de tiempo que solo el tiempo de consulta de más de 30 segundos. desde Ping es ICMP y su conexión DB es TCP, también se ha configurado / apretón de manos, y la iniciación de conexión DB etc en allí también

— Doon

@Doon: Que podría "evitarse" con conexiones TCP / bases de datos persistentes

— Michuelnik

@Michuelnik, ¿crees que la conexión DB persistente es el camino a seguir aquí? ¿Causará otros problemas?

— Phil

@michuelnik, por supuesto. Solo señalaba que no es tan simple como RTT + Query. También hay límites para la velocidad máxima, por sesión debido a la latencia, etc.)

— Doon

@phil En la mayoría de los casos, las conexiones de base de datos persistentes son beneficiosas, si va a hacer múltiples consultas. Si las consultas se extienden / son esporádicas, está atando recursos innecesariamente, pero si las consultas llegan todo el tiempo, etc., ahorrará una cantidad no trivial de sobrecarga al reutilizar la conexión existente en lugar de abrir una nueva en cada solicitud.

— Doon