rendimiento del zócalo en Linux

A raíz de mi última pregunta:rendimiento del zócalo en Linux

Performance issue using Javas Object streams with Sockets

estoy viendo el rendimiento toma en Linux. Con el ejemplo anterior, obtengo un tiempo de ida y vuelta de ~ 65 μ seg. Si hago dos fifos en el sistema de archivos, esto baja a ~ 45 μ seg. El tiempo adicional que usa los sockets de localhost debe ser porque estoy llegando a la pila de la red.

¿Hay alguna configuración del sistema operativo que puede hacer una toma de localhost ir tan rápido como una tubería con nombre?

uname -a 
Linux fiatpap1d 2.4.21-63.ELhugemem #1 SMP Wed Oct 28 23:12:58 EDT 2009 i686 athlon i386 GNU/Linux

¡Gracias de antemano!

Fuente

2010-07-27 Jonathan

¿Está usando un núcleo basado en 2.4? Eso es parte del problema. –

Sí, también uso un tocadiscos;) ¿Sabe si la versión posterior del kernal optimizará el tráfico de la red local de forma diferente? – Jonathan

Probablemente no, ¿podría explicar por qué no es adecuado usar tubos con nombre? ¿Has probado usar UDP en lugar de TCP? (DatagramSocket) – Ivan

no puedo ayudar en el frente de Java, pero se puede echar un vistazo a los zócalos de dominio UNIX. He aquí una pregunta con la discusión sobre la forma de utilizarlos en Java:

UNIX socket implementation for Java?

Fuente

2010-07-27 16:05:15

Sí, podría usar algo basado en jni. Prefiero no hacer esto si es posible. Esperaba que alguna versión posterior de Linux hiciera esta optimización para mí. – Jonathan

Sus preguntas anteriores hacen dos supuestos falsos:

ICMP_ECHO (también conocido como ping) los rendimientos de información de tiempo significativo. No lo hace, porque, entre otras cosas, la capa ICMP puede ser (y debería ser) con una prioridad de servicio baja.
Que la recopilación de datos a través de miles de interfaces Java no es el cuello de botella. Porque es.

Sus métodos de prueba son muy sospechosos. ¿Qué está tratando de lograr?

Fuente

2010-07-27 16:15:29 msw

Infierno sí. Gran respuesta. Maldita sea esas innumerables interfaces Java y su costo de rendimiento. –

Activado 1. El ping me está dando ~ al mismo tiempo que mi prueba usando canalizaciones con nombre. En 2. ¿Cómo ha llegado a esa conclusión? – Jonathan

Con el ejemplo anterior obtengo un tiempo de ida y vuelta de ~ 65μsec. Si hago dos fifos en el sistema de archivos, esto se reduce a ~ 45 μsec. El tiempo adicional que usa los sockets de localhost debe ser porque estoy llegando a la pila de la red.

Sí, y eso es de esperar.

Los FIFO son un método de comunicación bastante primitivo. Su estado es esencialmente una variable bool. Las lecturas y escrituras pasan por el mismo búfer preasignado de tamaño fijo. Por lo tanto, el sistema operativo puede optimizar y optimiza las operaciones.

Los zócalos son más complejos. Tienen una máquina de estado de TCP completa. El almacenamiento en búfer es dinámico y bidireccional (recv, send se almacenan en búfer por separado). Eso significa que cuando escribes algo en el socket local, casi siempre tienes algún tipo de administración de memoria dinámica involucrada. Linux trata de evitar eso tanto como sea posible: se implementan trucos de copia cero/copia única por todas partes. Sin embargo, obviamente, dado que las llamadas tienen que pasar por más código, serían más lentas.

Al final, teniendo en cuenta la cantidad de sockets que se comparan con los FIFO, 20us de diferencia es, francamente, una afirmación sobre lo bueno que es el rendimiento del socket de Linux.

P.S. 65us rtt = ~ 35us en una dirección. 1s/35us = ~ 30K paquetes por segundo. Para código de red sin optimizaciones usando una sola conexión que suena bien.

Fuente

2010-07-28 11:22:26 Dummy00001

Respuesta

Cuestiones relacionadas