Hablemos de latencia

Jose Luis Reyes
Apr 10 · 5 min read

Supongamos que tus usuarios están en Chile y requieres que tu aplicación tenga una respuesta veloz. ¿Da lo mismo tener un servidor virtual en AWS, en alguna región de EEUU, o uno alojado en un datacenter en Chile? La respuesta es no. Claro que la respuesta puede ser menos clara, dependiendo de lo que tú consideres “veloz”. Sin embargo, de todas formas, la velocidad de respuesta será muy diferente.

Velocidad y latencia

¿De qué depende la “velocidad”? De varios factores, como el ancho de banda de tu conexión, el uso que se le da a ese ancho de banda, la tasa de contención, la carga de tu servidor y, claro, de la latencia

Partamos por explicar qué es latencia. Ésta es básicamente el tiempo que tarda un dato en estar disponible desde que se realiza su petición. Es decir, por ejemplo, el tiempo que tarda tu usuario en recibir un paquete desde el servidor. La latencia se mide en milisegundos. A más milisegundos, mayor latencia, y por lo tanto más se demorará la transmisión de datos entre tus servidores y los ordenadores de tus usuarios.

Esto es muy distinto al ancho de banda, que tiene relación con la dimensión de los paquetes que puedes recibir. A mayor ancho de banda, puedes recibir más paquetes simultáneamente y de mayor tamaño.

Hay un factor que es clave en la latencia: la proximidad entre tus usuarios y tus servidores, explicado técnicamente por lo que llamamos RTT o Round Trip Time, que es el tiempo que le toma a la luz y, por ende, a cualquier señal recorrer el espacio desde su lugar de emisión (por ejemplo, el equipo del usuario) y su destino (el servidor), ida y vuelta. Es principalmente un tema geográfico. Otros factores, menos relevantes, que influyen en la latencia son la eficiencia de la red y la calidad de los dispositivos de enrutamiento.

El RTT o Round Trip Time mide el tiempo que toman los viajes de la petición y la respuesta, desde, por ejemplo, un equipo a un servidor.

Este efecto de ida y vuelta se ve acumulado y multiplicado por la cantidad de objetos, como imágenes, hojas de estilo, scripts, fuentes y otros, que se deban recuperar desde el servidor remoto hasta poder mostrar el contenido en el navegador. Una página web promedio tiene 75 objetos o assets, los cuales deben ser descargados por el navegador por lo general en grupos de no más de 6 objetos a la vez. Es decir, solo por concepto de RTT, las diferencias entre latencias pueden verse incrementada en 12 veces entre una ubicación geográfica y otra.

Sorpresas al medir latencias

¿Cómo puedes medir la latencia? Enviando una señal en un paquete ICMP y calculando el tiempo que le toma ir y volver al destino mediante la herramienta ping. Solo basta abrir la consola desde un equipo y tipear “ping” y luego la IP de tu servidor.

En pruebas realizadas por el equipo de Linets desde Santiago de Chile, con un enlace de 1 Gbit nacional y 100 Mbit internacional, las diferencias de latencia son brutales. Al probar conectarnos a una instancia de BeeBop, la nube pública de Linets, que tiene su datacenter en Santiago, la latencia fue de 1,865 ms. Al tratar de conectarnos a una región de EEUU de AWS, el resultado fue de 137,768 ms. No muy lejos estuvieron los resultados con Google Cloud Platform y Azure, al conectarnos a servidores ubicados en EEUU: 168,081 ms en el caso de GCP y 161,240 ms en el de Azure.

Y eso es solo porque la petición debe viajar hasta EEUU y la respuesta realizar un viaje similar de vuelta. Por lo mismo, cuando hemos realizado pruebas a clientes, mostrándoles cómo se comporta su aplicación, alojada fuera del país, en servidores ubicados en Chile, lo que hemos visto son caras de asombro.

En un blog llamado Dareboost quisieron ver en números cómo afecta la latencia en la carga de un sitio web. Para ello utilizaron como prueba su propio sitio web (dareboost.com) y realizaron varios test con el mismo ancho de banda de 8 Mb/s de descarga 1,5 Mb/s de subida, pero diferentes latencias, que se movieron entre los 25 milisegundos y los 150. El resultado fue que con una latencia de 25 ms el sitio se cargaba más del doble de rápido que con una latencia de 150 milisegundos.

No contentos, decidieron estudiar el efecto del ancho de banda en la carga del sitio. Para ello probaron desde 1 Mb/s de descarga y 0,5 Mb/s de subida hasta 200 Mb/s de descarga y 20 Mb/s de subida, con igual latencia entre ellos. Como era de esperarse, el ancho de banda solo tuvo efecto cuando generaba un cuello de botella en la descarga del sitio. Una vez que los anchos de banda dejaron de ser un cuello de botella (en este caso, después de de los 8 Mb/s de descarga y 2 Mb/s de subida), los tiempos de carga del sitio se mantuvieron constantes.

CDN versus cercanía al servidor

¿Y utilizando un content delivery network (CDN)?, ¿qué tanto puedes reducir el impacto de la latencia? Según datos de los propios proveedores de estos servicios puedes reducir en promedio un 73% la latencia y en algunos casos eliminar casi por completo la latencia.

Claro que hay un pero… Un CDN es muy útil para entregar contenido estático como imágenes, PDF, CSS, entre otros, pero cuando requieres procesar información en línea no te sirve de mucho. Es aquí donde tener mejores tasas de latencia pueden entregar un mejor rendimiento en tus sistemas, sin agregar esquemas arquitectónicos adicionales a los sistemas existentes.

Aterricemos esto. ¿En qué casos puedo requerir procesar información en línea o entregar contenido en base a interacciones del cliente? En las calculadoras de costo de envío, los carritos de compra, las pasarelas de pago, las recomendaciones basadas en el historial de compras del cliente, los sistemas transaccionales como los bancarios, en un ERP, entre otros.

Ligado a esto están las integraciones de servicios dentro de tu propio desarrollo. En Linets, por ejemplo, trabajamos con aplicaciones alojadas en Chile que tienen integraciones con servicios de venta, stock, productos, entre otros, publicados en AWS y en datacenter chilenos. Los servicios alojados a nivel nacional suelen tener mejores tiempos de respuesta, de hasta 2 a 4 veces más que aquellos ubicados en AWS, solo por estar ambos sistemas en chile. Y esto no es cacheable.

En definitiva, si tus sistemas están alojados en Chile, obtendrás mejores tasas de transferencia, sin hacer esfuerzo extra, y podrás integrar o transferir volúmenes de información importantes en muchos escenarios, sin agregar esquemas o aplicativos extras para contener esta información a transferir.

Se agradece la colaboración de Miguel Cantillana y Fabián Arias.

LINETS Tech Talk

Un espacio para compartir experiencias, ideas y rants.

Jose Luis Reyes

Written by

LINETS Tech Talk

Un espacio para compartir experiencias, ideas y rants.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade