Metodologías para probar el rendimiento de un enlace WAN

11

Tenemos un par de nuevos enlaces Ethernet de 1 Gbps enrutados de manera diversa entre ubicaciones a unas 200 millas de distancia. El 'cliente' es una nueva máquina razonablemente potente (HP DL380 G6, E56xx Xeons duales, 48 GB DDR3, par R1 de discos SAS de 300 GB a 10 krpm, W2K8R2-x64) y el 'servidor' también es una máquina lo suficientemente decente (HP BL460c G6 , doble E55xx Xeons, 72 GB, par R1 de discos SAS de 146 GB a 10 krpm, HBA Emulex 4Gbps FC de doble puerto vinculado a doble Cisco MDS9509s y luego en HP EVA 8400 dedicado con discos FC 128 x 450 GB 15 krpm, RHEL 5.3-x64).

Al utilizar SFTP desde el cliente, solo vemos unos 40 Kbps de rendimiento utilizando archivos grandes (> 2 GB). Hemos realizado pruebas de servidor a 'otro servidor local' y vemos alrededor de 500 Mbps a través de los conmutadores locales (Cat 6509s), haremos lo mismo en el lado del cliente, pero eso está a un día de distancia.

¿Qué otros métodos de prueba usaría para demostrar a los proveedores de enlaces que el problema es suyo?

networking performance sftp

— Chopper3
fuente

También me gustaría saber una respuesta a esta. Tenemos nuestra línea alquilada de 100Mbit instalada la próxima semana en algún momento :)

— Tom O'Connor

como dice user37899: los resultados serían apreciados.

— pQd

¿Alguna actualización? Tengo curiosidad por cómo resulta este.

— Kyle Brandt

Golpeé a los proveedores de enlaces "bastante mal" (irónicamente, ¡son parte de la misma organización para la que trabajo!). Aún no han regresado a nosotros.

— Chopper3

1

Ah, está bien, y por cierto, si puedes averiguar por qué obtengo 7 votos para serverfault.com/questions/134467/… y 1 para esto, me gustaría saber ;-)

— Kyle Brandt el

10

Tuning an Elephant:
Esto podría requerir un ajuste, probablemente no sea el problema aquí, como dice pQd. Este tipo de enlace se conoce como "Long, Fat Pipe" o elefante (ver RFC 1072 ). Debido a que este es un tubo gigabit grueso que recorre una distancia (la distancia es realmente tiempo / latencia en este caso), la ventana de recepción de tcp debe ser grande (consulte el volumen ilustrado TCP / IP 1, sección Extensiones TCP para ver las imágenes).

Para determinar cuál debe ser la ventana de recepción, calcule el producto de retraso de ancho de banda:

Bandwidth * Delay = Product

Si hay una latencia de 10MS, esta calculadora estima que desea una ventana de recepción de aproximadamente 1.2 MBytes. Podemos hacer el cálculo nosotros mismos con la fórmula anterior:

echo $(( (1000000.00/.01)/8  )) 
12500000

Por lo tanto, es posible que desee ejecutar un volcado de paquetes para ver si la escala de la ventana tcp (la extensión TCP que permite ventanas más grandes) está sucediendo correctamente para ajustar esto una vez que descubra cuál es el gran problema.

Límite de ventana:
si este es el problema, que tiene un tamaño de ventana limitado sin escala, esperaría los siguientes resultados si no se aplica una escala de ventana y hay una latencia de aproximadamente 200 ms, independientemente del tamaño de la tubería:

Throughput = Recieve Window/Round Trip Time

Entonces:

echo $(( 65536/.2 ))
327680 #Bytes/second

Para obtener los resultados que está viendo, solo necesitaría resolver la latencia, que sería:

RTT = RWIN/Throughput

Entonces (para 40 kBytes / s):

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

(Por favor revise mis Matemáticas, y estas, por supuesto, no incluyen todos los gastos generales de protocolo / encabezado)

— Kyle Brandt
fuente

Sabes que me sentí un poco culpable por 'adelantarte' temporalmente en la repetición la otra semana, y la razón es por lo malditamente buenas que son tus respuestas, ¡y BOOM! incluso usas un shell para hacer tus cálculos, ¡no la Calculadora Mac de 1.5MB.app que hago! :) Gracias.

— Chopper3

1

También tiene buenas respuestas, y me gusta que tenga a alguien cercano, que mejora un poco el juego :-) La consulta rápida de Google me recuerda que también ha respondido a mis preguntas: serverfault.com/questions/107263/ ... . Realmente aprecio a los usuarios activos que intentan hacer que esta comunidad 'suceda'. Pero gracias por el complemento!

— Kyle Brandt

Yo tampoco, no hay nada que me guste más que saber que hemos ayudado a alguien que sentía que estaba solo con un problema frustrante, aparte del queso, por supuesto. Dicho esto, también odio cuando recibimos preguntas mal formuladas, ¿escuchaste mi pregunta en el podcast 82 de SO? ¡también obtuve una camiseta SF gratis!

— Chopper3

Escucho la mayoría de los podcasts pero me perdí ese, volveré y lo veré (probablemente este fin de semana).

— Kyle Brandt

Lo siento por ese pQd, en realidad siempre he leído tu nick como PDQ como en PDQ Bach: en.wikipedia.org/wiki/P._D._Q._Bach :-)

— Kyle Brandt

6

40 kbps es muy bajo [hasta el punto de que sospecharía que los convertidores de medios defectuosos / dúplex no coinciden [pero tiene gigabit, ¡así que no hay lugar para half duplex!], Etc.]. debe haber pérdidas de paquetes o muy alta inestabilidad involucrada.

iperf es la primera herramienta que se me ocurre para medir el rendimiento disponible. correr a un lado

iperf -s

y por el otro:

iperf -t 60 -c 10.11.12.13

luego puede intercambiar roles cliente / servidor, usar -d para dúplex, etc. ejecutar mtr entre ambas máquinas antes de comenzar la prueba y ver qué latencia / pérdida de paquetes tiene en el enlace no utilizado y cómo cambian durante la transferencia de datos.

le gustaría ver: fluctuaciones muy pequeñas y sin pérdidas de paquetes hasta que el enlace esté saturado al 90 por ciento de su capacidad.

iperf para * nix y win , lea aquí y aquí al respecto.

mtr para * nix y win .

— pQd
fuente

Sabemos que el enlace está compuesto por 6 enlaces de 1000-base-zx, por lo que es probable que se repita la latencia, pero aun así me sorprende lo bajo que es, excelente consejo sobre el iperf por manera, ¡había olvidado por completo que existía!

— Chopper3

por favor publique sus resultados!

— The Unix Janitor

1

tracepath puede mostrarle problemas de enrutamiento entre los dos sitios.

iperf, ttcp y bwping pueden brindarle información útil.

¿sabes cómo se aprovisiona este enlace de 1 GB? ¿Estás conectando o enrutando este enlace? ¿Cuál es su SLA para el enlace? podría ser moldeado por su proveedor de enlaces?

si solo obtiene 40kbs, entonces hay un problema grave, ¿está seguro de que no es un enlace de 1 MB en lugar de un enlace de 1 GB / s? Probablemente encontrará que la velocidad del enlace no es lo que usted piensa :-)

— El conserje de Unix
fuente

Gracias por su respuesta, es un enlace de fibra de modo único con puente multisegmento dedicado, no hay forma en absoluto involucrado, ya que solo es L2 en todo el camino, y espero que no sea un enlace de 1 Mbps, no con el dinero que está costando :)

— Chopper3

1

si se conecta a su LAN, es decir, no hay enrutamiento en ninguna parte, las transmisiones de la red desperdiciarán la capacidad del enlace, lo que es cierto para 1 gb será una pequeña fracción, pero un servicio de red que se comporta mal podría aplanar el enlace. Supongo que estos puentes están fuera de tu control. Estos interruptores pueden estar sobrecargados o tener una latencia muy alta. Alta latencia significa bajo ancho de banda.

— The Unix Janitor

@ user37899: la alta latencia no tiene que significar un ancho de banda bajo, pero requiere ajuste ... de todos modos, cuánta latencia puede obtener en 200 millas, si las cosas están bien, no más de 3-10 ms. La transmisión arp [u otra] en el enlace gigabit es probablemente una fracción muy pequeña de toda la capacidad disponible.

— pQd

1

Si tiene transmisiones de red que se producen a un nivel tal que afecte el rendimiento del enlace, entonces sospecho que habría tenido problemas de rendimiento internos mucho antes de que esta nueva línea entrara y lo hubiera notado.

— joeqwerty

@pQd en realidad estaba hablando de una tormenta de transmisión.

— El conserje de Unix

0

RFC 2544 o Y.156sam

Estas son pruebas de red que el operador realiza para probar el SLA. IPERF y similares no son métodos de prueba de red verificables.

— Ansel Gaddy
fuente