Creo una máquina virtual de Azure con SKU Standard_D1_v21en formato Southeast Asia. De acuerdo aeste doctor, el ancho de banda esperado es de 750 Mbps.
Sin embargo, pruebo el ancho de banda de la conexión desde mi máquina local a la VM y el resultado es de alrededor de 3 Mbps. La herramienta de prueba esiPerf3, con la VM como servidor iPerf3 y mi máquina local como cliente iPerf3. No hubo otra carga de trabajo de red pesada en la VM durante la prueba. Hice otra prueba a travésNTTTCPsiguió este resultado.
Entiendo que el ancho de banda real será menor de lo esperado por varios motivos, como por ejemplo:
- La conexión se realiza a través de regiones con muchos saltos.
- Las máquinas virtuales en infraestructura compartida comparten una limitación total (enlace).
- La VM se implementa en la región de menor latencia (Prueba de velocidad de Azure).
Pero el ancho de banda real (3Mbps) es mucho menor de lo esperado (750Mbps). Entonces, ¿cómo:
- ¿Solucionar las causas fundamentales? Una mala configuración en VM; o a muchos saltos en conexiones entre regiones; ¿O un acelerador en algún lugar de la infraestructura?
- ¿Cómo mejorar el ancho de banda entre la máquina local y la VM remota?
Respuesta1
¿Qué tal si haces algunas pruebas absolutamente obvias? Cosas que me hacen preguntarme si deberías preguntar a un superusuario que a un sitio para profesionales.
- Pruebe el ancho de banda en ambos puntos finales y en todos lados. Utilice una prueba que obtenga de Internet; muchas de ellas se ejecutan en el navegador. Speedtest.net le permite seleccionar el contrapunto, por lo que puede comenzar con un servidor local, luego usar el otro lado (al menos cerrar) y luego colgarse durante todo el camino.
Esencialmente: a menos que usted o la otra parte tengan un problema local, lo cual es poco probable a niveles de velocidad cómicos como los que usted logra, este es un problema de ruta y no hay NADA que pueda hacer, excepto 2 cosas:
- Hable con el soporte de su ISP
- Cambia tu proveedor de Internet.
El enrutamiento es su dominio. Es posible que hayan arruinado una ruta particular, pero si no, bueno, no puedes hacer nada excepto buscar otro proveedor de Internet.
Su prueba (tal como está) es bastante inútil, porque solo prueba de A a B, no si hay un problema local en algún lado. Con mi enfoque puedes variar el contrapunto y ver, por ejemplo, si tu máquina local tiene problemas en destinos particulares. Puede ser que tengas buen ancho de banda local, pero los enlaces internacionales estén sobrecargados.
Si eso funciona, es hora de comprobar el sistema operativo utilizado. RSS está ahí por una razón: aumenta la cantidad de paquetes "en vuelo" que pueden ser necesarios para pings largos.
Además de eso, realmente no hay nada que PUEDES hacer.
Respuesta2
Bienvenido al foro.
El problema aquí es que no controlas los puntos intermedios. Encontrar esta granularidad es en parte ciencia y en parte arte, ya que no existe una única respuesta realmente buena, sino más bien un informe sobre los hallazgos de muchos factores.
Ubicar un cuello de botella correctamente significaría poder probar todos los puntos entre hacia y desde cada lado, nunca tendrá acceso a todos ellos, pero puede inferir algunas cosas y ver muchos ángulos para obtener una mejor imagen.
Las cosas que puede eliminar son "¿Tiene un rendimiento adecuado de su lado?" Esto se puede lograr si tiene un sitio conocido con ancho de banda dedicado para realizar pruebas y una buena ruta conocida capaz de mantener su rendimiento. Las pruebas de velocidad en línea pueden ser engañosas, porque es posible que usted tenga una conexión adecuada y ELLOS tengan el ancho de banda adecuado para realizar las pruebas de manera confiable. Pero ninguno de ustedes controla lo que sucede entre usted y ellos. SI constantemente obtiene buenas pruebas de velocidad en múltiples sitios de prueba, entonces puede descartar con relativa seguridad que el problema esté de su lado, en la medida en que lo controle. La otra cara, por supuesto, si esa falla en todos aún no es usted, podría ser el ISP de su ISP, alguien en una red central en algún lugar, alguna ruta congestionando a otra para permanecer activa, etc. En cuyo caso, si puede preguntarle a su ISP involucrarse, pero en una línea de consumo le lanzarán "Speeds up to", en una línea de negocios dedicada tiene un argumento, pero aún así una carga de prueba.
Aunque no es imposible, no es probable que el punto de estrangulamiento esté en el lado azul, a menos que tengas un peso corporal limitado contractualmente.
Puedes hacer cosas como usar MTRhttps://en.wikipedia.org/wiki/MTR_(software)Para obtener una breve descripción general, pero tenga en cuenta que la caída de ICMP puede ser el resultado del funcionamiento natural de los sistemas, ya que la mayoría de los equipos de red descartarán ICMP bajo estrés y algunos simplemente están configurados para no responder de forma predeterminada. Entonces, aunque esto puede darle más información para continuar, no es una prueba irrefutable; debe comprender cómo leerla e interpretarla.
Puedes buscar lugares como aquí.https://www.thousandeyes.com/outages/donde se registran cortes importantes a través de redes de sensores en todo el mundo. A veces, eso puede darle una pista, especialmente en la red AS (los nodos centrales de Internet en términos simples) si uno tiene problemas que afectan directamente su ruta.
Para interpretar eso y determinar cuál es "su" ruta, puede comenzar con las herramientas BGP de HE aquíhttps://bgp.he.net/verás efectivamentedóndeen Internet estás en el sentido de enrutamiento. SI hace clic en la IP que utiliza para acceder a Internet (comúnmente conocida como su IP pública), verá algo como esto...
Esto es quién es usted en Internet (desde dónde lo visita), de qué red viene (se anuncia como) y cómo ingresa a "Internet" (su ISP).
Se puede rastrear de ASN a ASN (número de sistema autónomo) para ver la ruta real que toma (en ese momento, ya que está sujeta a cambios sin previo aviso para mantener las rutas abiertas) o incluso mirarla en un gráfico.
Luego, puede comparar con el gráfico de los mil ojos o con una multitud de otras herramientas de informes BGP en línea para ver si esas rutas tienen congestión conocida o si están aleteando (subiendo y bajando), etc.
Por lo general, eso le brindará suficiente información para notificar quién puede estar a cargo de qué sistema (tenga en cuenta que a la mayoría no le importará más allá de su ISP) y, aunque es posible que eso no lo lleve a donde desea estar, explica por qué no está donde desea. quiero ser.
Considerándolo todo, debes pensarlo así: la velocidad no es constante en todo Internet, algunas secciones están conectadas a través de enlaces increíblemente rápidos, otras no tanto. Y cuando uno de esos grandes se cae, muchos más pequeños sufren mucho.
Entonces, ¿qué puede hacer usted al respecto? A vecesPuede evitarlo si realiza conexiones de igual a igual, pero hacerlo no garantizará que todos sus clientes que viajan por las mismas rutas tengan la misma experiencia. Por ejemplo, podría tener un servidor web allí y podría obtener una conexión sólida y de buen rendimiento con algo como un proveedor de VPN que salga más cerca de su extremo remoto y lo obligue a tomar una mejor ruta. Los usuarios que vayan a su servidor y no hagan lo mismo no tendrán la misma experiencia. Hay algunos servicios que pueden hacer esto pagando una tarifa por todo, haciendo que su servidor aparezca en otro lugar de donde realmente está y tomando una ruta premium. Posiblemente cloudflare tenga servicios como este, nunca lo he usado, así que tendría que dejar que un experto en cloudflair intervenga en eso.
Con suerte, esto le dará lo suficiente para comprender cómo esto puede volverse complicado y también comprender que su experiencia y la de alguien a un estado de distancia podrían ser completamente diferentes.