Java I/O contra Java I/O nueva (NIO) con Linux NPTL

Question

Mis servidores web utilizan la I/O Java habitual con subprocesos por mecanismo de conexión. Hoy en día, se están poniendo de rodillas con un mayor número de usuarios (conexión larga de sondeo). Sin embargo, las conexiones son en su mayoría inactivas. Si bien esto se puede resolver agregando más servidores web, he estado tratando de investigar sobre la implementación de NIO.

Tengo una impresión mixta al respecto. He leído sobre benchmarks donde la E/S regular con la nueva biblioteca NPTL en Linux supera a NIO.

¿Cuál es la experiencia de la vida real de configurar y utilizar el último NPTL para Linux con Java I/O? ¿Hay algún aumento en el rendimiento?

Y sobre una cuestión de mayor alcance:

¿Cuál es el número máximo de subprocesos de E/S y de bloqueo (que configuramos en la piscina Tomcat hilo) en una máquina de tipo servidor estándar (Dell un procesador de cuatro núcleos) que esperamos que funcione normalmente (con la biblioteca Linux NPTL?). ¿Cuál es el impacto si el hilo de rosca se pone realmente grande, digamos más de 1000 hilos?

Todas las referencias y sugerencias serán muy apreciadas.

Answer 1

provocativa de Publicación, (2008) blog reclamaciones de "Avoid NIO, get better throughput." Paul TYMA ~ 5000 hilos sin ningún problema; la gente que he oído demandan más:

1. Con NTPL en, Sol y Blackwidow JVM 1.4.2 fácilmente escalables a más de 5.000 hilos. El modelo de bloqueo fue consistentemente 25-35% más rápido que con selectores NIO. Muchas técnicas sugeridas por gente de EmberIO fueron empleadas - usando múltiples selectores, haciendo múltiples (2) lecturas si la primera lectura devolvió el equivalente de EAGAIN en Java. Sin embargo, no podíamos vencer al hilo simple por modelo de conexión con Linux NPTL.

Creo que la clave aquí es measure the overhead and performance, y dar el paso a no bloqueo de E/S sólo cuando se sabe que necesita y puede demostrar una mejora. El esfuerzo adicional para escribir y mantener el código que no bloquea debe tenerse en cuenta en su decisión. Mi opinión es si su aplicación se puede expresar limpiamente utilizando E/S síncronas/bloqueantes, HAGA ESO. Si su aplicación es compatible con E/S sin bloqueo y no solo va a reinventar mal las E/S de bloqueo en el espacio de la aplicación, CONSIDERE cambiando a nio según las necesidades de rendimiento medido. Me asombra cuando busco en los resultados de google para ver cómo algunos de los recursos realmente citan números (recientes)!

También, vea Paul Tyma's presentation slides: La forma antigua es nueva de nuevo. En base a su trabajo en Google, las cifras concretas sugieren que la E/S con subprocesos sincronizados es bastante escalable en Linux, y consideran que "NIO es más rápido", un mito que fue cierto por un tiempo, pero ya no. Algunos buenos comentarios adicionales here on Comet Daily. Él cita el siguiente (, todavía hay un vínculo sólido con puntos de referencia anecdótica, etc ...) como resultado de NTPL:

En las pruebas, NTPL tuvieron éxito en el inicio de 100.000 hilos en un IA-32 en dos segundos. En comparación, esta prueba bajo un núcleo sin NPTL habría tomada alrededor de 15 minutos

Si realmente está ejecutando en problemas de escalabilidad, es posible que desee utilizar tune the thread stack sizeXX:ThreadStackSize. Como mencionas Tomcat see here.

Finalmente, si está obligado y determinado a utilizar E/S sin bloqueo, haga todo lo posible para construir en un existing framework by people who know what they're doing. He desperdiciado demasiado de mi tiempo tratando de obtener una intrincada solución de E/S sin bloqueo (por las razones equivocadas).

Véase también related on SO.

Answer 2

Los enlaces que pueden ser de utilidad:

• Handling of 100.000+ open connections
• The C10K problem
• Scalable Network Programming

También puede echar un vistazo a http://nodejs.org/ que no es una JVM en la tecnología, pero perfectamente maneja miles de conexiones (y, si no me equivoco, usa NPTL detrás de las escenas)

Algunas buenas probadas marcos web NIO bajo JVM:

• Project Grizzly (Glassfish subproject)
• Netty
• Apache MINA

Answer 3

Espero que cualquier servidor con memoria suficiente para manejar decenas de miles de hilos inactivos fácilmente, tal vez cientos de miles.

Answer 4

Sajid, veo que estás haciendo Comet (larga encuesta).

Casi nadie habla sobre el problema de ejecutar el código de usuario para los eventos Comet en NIO. El hilo de NIO que distribuye los eventos de Comet llama a su código, si su código no es lo suficientemente bueno está bloqueando este hilo crítico y otras conexiones de COMET DEBEN ESPERAR porque el hilo de NIO está haciendo un trabajo similar al programador de hilos del SO. Este no es el problema en Comet con IO porque el hilo es solo para su evento/tarea Comet y el planificador puede renunciar a su hilo cuando lo desee (no es tan fácil con un enfoque de NIO).

El único problema que veo con "Comet sincrónico" (basado en IO) es el consumo de memoria de las pilas de subprocesos.