En este momento estamos tratando de decidir si trasladamos nuestro centro de datos de la costa oeste a la costa este.
Sin embargo, estoy viendo algunos números de latencia inquietantes desde mi ubicación en la costa oeste hasta la costa este. Aquí hay un resultado de muestra, recuperando un pequeño archivo de logotipo .png en Google Chrome y usando las herramientas de desarrollo para ver cuánto tiempo tarda la solicitud:
- Costa oeste a costa este:
215 ms de latencia, 46 ms de tiempo de transferencia, 261 ms en total - Costa oeste a costa oeste:
latencia de 114 ms, tiempo de transferencia de 41 ms, total de 155 ms
Tiene sentido que Corvallis, OR esté geográficamente más cerca de mi ubicación en Berkeley, CA, por lo que espero que la conexión sea un poco más rápida ... pero veo un aumento en la latencia de + 100 ms cuando realizo la misma prueba en Nueva York. servidor. Eso parece ... excesivo para mí. Particularmente porque el tiempo dedicado a transferir los datos reales solo aumentó un 10%, ¡pero la latencia aumentó un 100%!
Eso se siente ... mal ... para mí.
Encontré algunos enlaces aquí que fueron útiles (¡a través de Google, nada menos!) ...
- ¿La distancia de enrutamiento afecta significativamente el rendimiento?
- ¿Cómo afecta la geografía a la latencia de la red?
- Latencia en las conexiones a Internet de Europa a EE. UU.
... pero nada autoritario.
Entonces, ¿es esto normal? No se siente normal. ¿Cuál es la latencia "típica" que debo esperar al mover paquetes de red desde la costa este <--> costa oeste de los Estados Unidos?
fuente
Respuestas:
Velocidad de la luz:
no vas a superar la velocidad de la luz como un punto académico interesante. Este enlace funciona Stanford a Boston en ~ 40 ms mejor tiempo posible. Cuando esta persona hizo el cálculo, decidió que Internet funciona a aproximadamente "dentro de un factor de dos de la velocidad de la luz", por lo que hay aproximadamente ~ 85 ms de tiempo de transferencia.
Tamaño de la ventana TCP:
si tiene problemas de velocidad de transferencia, es posible que deba aumentar el tamaño de la ventana de recepción tcp. Es posible que también deba habilitar el escalado de ventanas si se trata de una conexión de gran ancho de banda con alta latencia (denominada "tubería larga y gruesa"). Entonces, si está transfiriendo un archivo grande, necesita tener una ventana de recepción lo suficientemente grande como para llenar la tubería sin tener que esperar las actualizaciones de la ventana. Entré en detalles sobre cómo calcular eso en mi respuesta Tuning an Elephant .
Geografía y latencia:
un punto de falla de algunas CDN (Redes de distribución de contenido) es que equiparan la latencia y la geografía. Google investigó mucho con su red y encontró fallas en esto, publicó los resultados en el documento técnico Mover más allá de la información de ruta de extremo a extremo para optimizar el rendimiento de CDN :
Emparejamientos de BGP:
también si comienza a estudiar BGP (protocolo de enrutamiento central de Internet) y cómo los ISP eligen emparejamientos, encontrará que a menudo se trata más de finanzas y política, por lo que es posible que no siempre obtenga la 'mejor' ruta a ciertas ubicaciones geográficas dependiendo en tu ISP. Puede ver cómo se conecta su IP a otros ISP (sistemas autónomos) utilizando un enrutador de espejo . También puede usar un servicio whois especial :
También es divertido explorarlos como pares con una herramienta de interfaz gráfica de usuario como linkrank , que te da una imagen de Internet a tu alrededor.
fuente
Este sitio sugeriría una latencia de alrededor de 70-80 ms entre la costa este / oeste de los Estados Unidos (San Francisco a Nueva York, por ejemplo).
Aquí están mis horarios (estoy en Londres, Inglaterra, así que mis tiempos en la costa oeste son más altos que en el este). Obtengo una diferencia de latencia de 74 ms, que parece respaldar el valor de ese sitio.
Estos se midieron utilizando las herramientas de desarrollo de Google Chrome.
fuente
71 msen ello, así que tienes razón: no podemos esperar hacerlo mejor que eso.Mida primero con ICMP si es posible. Las pruebas ICMP generalmente usan una carga útil muy pequeña de manera predeterminada, no usan un protocolo de enlace de tres vías y no tienen que interactuar con otra aplicación en la pila como lo hace HTTP. Cualquiera sea el caso, es de suma importancia que los resultados HTTP no se mezclen con los resultados ICMP. Son manzanas y naranjas.
Siguiendo la respuesta de Rich Adams y utilizando el sitio que él recomendó, puede ver que en el backbone de AT&T, el tráfico ICMP tarda 72 ms en moverse entre sus puntos finales SF y NY. Es un número razonable, pero debe tener en cuenta que está en una red que está completamente controlada por AT&T. No tiene en cuenta la transición a la red de su hogar u oficina.
Si hace un ping contra careers.stackoverflow.com desde su red de origen, debería ver algo no muy lejos de 72 ms (quizás +/- 20 ms). Si ese es el caso, entonces probablemente pueda suponer que la ruta de red entre los dos está bien y se ejecuta dentro de los rangos normales. Si no, no se asuste y mida desde otros lugares. Podría ser tu ISP.
Suponiendo que eso pasó, su próximo paso es abordar la capa de aplicación y determinar si hay algún problema con la sobrecarga adicional que está viendo con sus solicitudes HTTP. Esto puede variar de una aplicación a otra debido al hardware, el sistema operativo y la pila de aplicaciones, pero dado que tiene un equipo más o menos idéntico en las costas este y oeste, podría hacer que los usuarios de la costa este golpeen los servidores de la costa oeste y los usuarios de la costa oeste golpeen el este costa. Si ambos sitios están configurados correctamente, esperaría ver que todos los números sean menos iguales y, por lo tanto, demostrar que lo que está viendo es bastante común para lo grueso.
Si esos tiempos HTTP tienen una amplia variación, no me sorprendería si hubiera un problema de configuración en el sitio de rendimiento más lento.
Ahora, una vez que esté en este punto, puede intentar hacer una optimización más agresiva en el lado de la aplicación para ver si esos números se pueden reducir. Por ejemplo, si está utilizando IIS 7, ¿está aprovechando sus capacidades de almacenamiento en caché, etc.? Tal vez podrías ganar algo allí, tal vez no. Cuando se trata de ajustar elementos de bajo nivel como las ventanas TCP, soy muy escéptico de que tenga un gran impacto para algo como Stack Overflow. Pero bueno, no lo sabrás hasta que lo pruebes y lo midas.
fuente
Varias de las respuestas aquí están usando ping y traceroute para sus explicaciones. Estas herramientas tienen su lugar, pero no son confiables para la medición del rendimiento de la red.
En particular, (al menos algunos) enrutadores Juniper envían el procesamiento de eventos ICMP al plano de control del enrutador. Esto es MUCHO más lento que el plano de reenvío, especialmente en un enrutador de red troncal.
Existen otras circunstancias en las que la respuesta ICMP puede ser mucho más lenta que el rendimiento de reenvío real de un enrutador. Por ejemplo, imagine un enrutador totalmente de software (sin hardware de reenvío especializado) que esté al 99% de la capacidad de la CPU, pero que todavía esté moviendo bien el tráfico. ¿Desea que pase muchos ciclos procesando respuestas de traceroute o reenviando tráfico? Por lo tanto, procesar la respuesta es una prioridad súper baja.
Como resultado, ping / traceroute le da límites superiores razonables (las cosas van al menos tan rápido), pero en realidad no le dicen qué tan rápido va el tráfico real.
En cualquier evento -
Aquí hay un ejemplo de trazado de ruta desde la Universidad de Michigan (centro de EE. UU.) Hasta Stanford (costa oeste de EE. UU.). (Resulta que pasa por Washington, DC (costa este de EE. UU.), Que está a 500 millas en la dirección "incorrecta".
En particular, observe la diferencia de tiempo entre los resultados del traceroute del enrutador de lavado y el enrutador atla (saltos 7 y 8). la ruta de red va primero a lavar y luego a atla. el lavado tarda 50-100 ms en responder, el atla tarda unos 28 ms. Claramente, el atla está más lejos, pero sus resultados de traceroute sugieren que está más cerca.
Consulte http://www.internet2.edu/performance/ para obtener mucha información sobre la medición de red. (descargo de responsabilidad, solía trabajar para internet2). Ver también: https://fasterdata.es.net/
Para agregar alguna relevancia específica a la pregunta original ... Como puede ver, tuve un tiempo de ping de ida y vuelta de 83 ms para Stanford, por lo que sabemos que la red puede ir al menos tan rápido.
Tenga en cuenta que la ruta de la red de investigación y educación que tomé en este trazado es probable que sea más rápida que una ruta de Internet de productos básicos. Las redes de R&E generalmente sobreaprovisionan sus conexiones, lo que hace poco probable el almacenamiento en búfer en cada enrutador. Además, tenga en cuenta el largo camino físico, más largo que de costa a costa, aunque claramente representativo del tráfico real.
michigan-> washington, dc-> atlanta-> houston-> los angeles-> stanford
fuente
Veo diferencias consistentes y estoy sentado en Noruega:
Esto se midió con el método científico exacto y comprobado de usar la vista de recursos de Google Chrome y simplemente actualizar repetidamente cada enlace.
Traceroute a serverfault
Traceroute a carreras
Desafortunadamente, ahora comienza a entrar en un bucle o algo así y continúa dando estrellas y tiempo de espera hasta 30 saltos y luego termina.
Tenga en cuenta que las rutas de seguimiento son de un host diferente a los tiempos al inicio, tuve que RDP a mi servidor alojado para ejecutarlos
fuente
Veo una latencia de aproximadamente 80-90 ms en enlaces bien medidos y bien medidos entre las costas este y oeste.
Sería interesante ver dónde está ganando latencia: pruebe una herramienta como traceroute de capa cuatro (lft). Hay muchas posibilidades de que se gane en la "última milla" (es decir, en su proveedor local de banda ancha).
Es de esperar que el tiempo de transferencia se haya visto afectado ligeramente: la pérdida de paquetes y la fluctuación son medidas más útiles para observar cuando se investigan las diferencias de tiempo de transferencia entre dos ubicaciones.
fuente
Solo por diversión, cuando jugué al juego en línea Lineage 2 NA desde Europa:
La diferencia parece respaldar que hasta 100 ms está dentro de lo razonable, considerando la naturaleza impredecible de Internet.
Utilizando la aclamada prueba de actualización de Chrome, obtengo un tiempo de carga de documentos que difiere en aproximadamente 130 ms.
fuente
Todos aquí tienen algún punto realmente bueno. y son correctos en su propio POV.
Y todo se reduce a que no hay una respuesta exacta real aquí, porque hay tantas variables que cualquier respuesta dada siempre se puede probar que es incorrecta simplemente cambiando una de cien variables.
Al igual que la latencia de 72ms NY a SF es la latencia de PoP a PoP de un transportista de un paquete. Esto no tiene en cuenta ninguno de los otros grandes puntos que algunos han señalado aquí sobre congestión, pérdida de paquetes, calidad de servicio, paquetes fuera de servicio o tamaño de paquete, o redirigir la red solo entre el mundo perfecto de PoP a PoP .
Y luego, cuando agrega la última milla (generalmente muchas millas) desde el PoP a su ubicación real dentro de las dos ciudades donde todas estas variables se vuelven mucho más fluidas, ¡comienza a escalar exponencialmente a partir de una capacidad razonable de conjetura!
Como ejemplo, realicé una prueba entre la ciudad de Nueva York y SF en el transcurso de un día hábil. Hice esto un día en que no hubo "incidentes" importantes en todo el mundo que pudieran causar un aumento en el tráfico. ¡Entonces quizás esto no era normal en el mundo de hoy! Pero no obstante fue mi prueba. Realmente medí de una ubicación comercial a otra durante este período, y durante el horario comercial normal de cada costa.
Al mismo tiempo, supervisé los números de los proveedores de circuitos en la web.
Los resultados fueron números de latencia entre 88 y 100 ms de puerta a puerta de las ubicaciones comerciales. Esto no incluyó ningún número de latencia de red entre oficinas.
La latencia de las redes del proveedor de servicios osciló entre 70 y 80 ms. Lo que significa que la latencia de la última milla podría haber oscilado entre 18 y 30 ms. No correlacioné los picos y bajos exactos entre los dos entornos.
fuente
Tiempos de Nueva York:
Usando Chrome, en una conexión residencial.
Usando lft desde un VPS en un centro de datos en Newark, Nueva Jersey:
fuente