Multicast Send Performance

Recientemente completamos un análisis del rendimiento de envío de multidifusión. Afortunadamente, Java y C se desempeñaron casi de manera idéntica ya que probamos diferentes tasas de envío de tráfico en Windows y Solaris.Multicast Send Performance

Sin embargo, notamos que el tiempo para enviar un mensaje de multidifusión aumenta a medida que aumenta el tiempo entre envíos. Cuanto más frecuentemente llamemos enviar, menos tiempo tardará en completar la llamada de envío.

La aplicación nos permite controlar la cantidad de tiempo que esperamos entre llamar y enviar, a continuación verá que el tiempo aumenta a medida que aumenta la demora entre los paquetes. Cuando se envían 1000 paquetes/segundo (1 ms de tiempo de espera), solo se requieren 13 microsegundos para llamar al envío. Con 1 paquete/segundo (tiempo de espera de 1000 ms), ese tiempo aumenta a 20 microsegundos.

Wait time (ms)      us to send 
0         8.67 
1         12.97 
10         13.06 
100         18.03 
1000        20.82 
10000        57.20

Vemos este fenómeno tanto de Java como de C, tanto en Windows como en Solaris. Estamos probando en un servidor Dell 1950 con una tarjeta de red de puerto dual Intel Pro 1000. Micro-benchmarking es difícil, especialmente en Java, pero no creemos que esto esté relacionado con JITing o GC.

código de Java y la línea de comandos que estoy usando para las pruebas se encuentran en: http://www.moneyandsoftware.com/2009/09/18/multicast-send-performance/

Fuente

2009-09-18 Ted Graham

Algunas teorías:

Mi primer pensamiento fue que yo considero el almacenamiento en caché a ser un factor aquí - si el las tareas y los valores están todavía en la pila o en la memoria reciente a corto plazo, es posible que pueda enviarlos más rápido. A medida que aumenta el tiempo, la posibilidad de que siga disponible disminuye, por lo que, en promedio, tomaría más tiempo.

Sin embargo, esperaría que hubiera un límite superior si este fuera el caso ... algún punto en el que siempre está en caché.

Un razonamiento alternativo es que hay una pérdida de memoria o alguna degradación del rendimiento en el tiempo en su aplicación/prueba/plataforma. Esto también (si existe) significa que cuanto más espere, más tiempo tendrá para degradar el rendimiento y, por lo tanto, más tiempo le tomará enviar.

TAMBIÉN: si tarda más tiempo entre los paquetes para enviarlos, puede exceder los tiempos de espera de aprendizaje de la dirección, tanto tablas IP como tablas MAC. Si estas tablas/cachés han expirado, tendrían que volver a aprenderlas antes de reenviar el paquete.

¡Buena suerte!

Fuente

2009-09-18 14:37:02

Para verificar esta teoría, el OP debería probarse con unidifusión y ver un perfil similar en el análisis. – Stef

bueno, en teoría, pero la mayoría de los conmutadores/enrutadores con los que he trabajado mantienen tablas y cachés separados para unidifusión y multidifusión. Entonces ambos pueden tener los mismos tiempos de espera, pero IIRC también fueron configurables ... –

¿No los tiempos de espera en las tablas de enrutamiento darán como resultado que todo bajo el tiempo de espera sea la misma velocidad, mientras que todo es más lento?Pero vemos que se degrada gradualmente a medida que aumenta el tiempo entre los paquetes. –

El código para realizar esas tareas se guarda en caché más cerca de la CPU (tal vez incluso en los registros) cuando se acaba de realizar una llamada.

Fuente

2009-09-18 14:40:23

Si es verdadero, vería que el rendimiento de cualquier operación se degrada a medida que aumenta el tiempo entre las operaciones. Cambié la prueba para hacer un sqrt o tan en cambio y vemos una curva de disminución de rendimiento similar. ¿Utiliza la afinidad de la CPU y el blindaje de la manera correcta para solucionar esto? –

Podría ser un artefacto de interrupción de coalescencia con la NIC en ese servidor en particular, consulte este artículo de 29 West en el tema, que muestran cómo la latencia puede aumentar hasta 125μs en una e1000 NIC,

http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html

Fuente

2010-02-06 05:06:44

¿Cómo esperas entre los envíos? ¿Has intentado esperar ocupado para que no abandones la CPU?

Fuente

2010-02-06 09:22:15