Java I/O vs. Java I/O(NIO) con Linux NPTL
multithreading (4)
Los enlaces que puede encontrar útiles:
También puede consultar http://nodejs.org/ que no es una tecnología JVM, pero maneja perfectamente miles de conexiones (y, si no me equivoco, usa NPTL detrás de escena)
Algunos marcos web de NIO bien probados bajo JVM:
Mis servidores web utilizan la E / S de Java habitual con subprocesos por mecanismo de conexión. Hoy en día, se ponen de rodillas con el aumento de usuarios (conexión de sondeo largo). 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 un poco sobre la implementación de NIO .
Tengo una impresión mixta al respecto. He leído sobre los puntos de referencia donde la E / S regular con la nueva biblioteca NPTL en Linux supera a NIO.
¿Cuál es la experiencia de la vida real al configurar y usar la última NPTL para Linux con Java I / O? ¿Hay algún aumento de rendimiento?
Y en una pregunta de mayor alcance:
¿Cuál es el número máximo de E / S y subprocesos de bloqueo (que configuramos en el grupo de subprocesos de Tomcat ) en una máquina de clase de servidor estándar (Dell con un procesador de cuatro núcleos) que esperamos realizar normalmente (con la biblioteca Linux NPTL?). ¿Cuál es el impacto si la agrupación de hilos se hace realmente grande, digamos más de 1000 hilos?
Cualquier referencias y punteros serán muy apreciados.
Publicación de blog provocativa, "Evite NIO, obtenga un mejor rendimiento". El blog de Paul Tyma (2008) reclama ~ 5000 hilos sin ningún problema; He oído a la gente decir más:
- Con NPTL activado, Sun y Blackwidow JVM 1.4.2 se escalaron fácilmente a más de 5000 subprocesos. El modelo de bloqueo fue siempre un 25-35% más rápido que el uso de selectores NIO. Se emplearon muchas técnicas sugeridas por la gente de EmberIO: se utilizaron selectores múltiples y se realizaron varias (2) lecturas si la primera lectura devolvía el equivalente de EAGAIN en Java. Sin embargo, no pudimos superar el hilo sencillo por modelo de conexión con Linux NPTL.
Creo que la clave aquí es medir la sobrecarga y el rendimiento , y pasar a la E / S sin bloqueo solo cuando sepa que necesita y puede demostrar una mejora. El esfuerzo adicional para escribir y mantener el código de no bloqueo debe tenerse en cuenta en su decisión. Mi opinión es que, si su aplicación se puede expresar de forma limpia mediante E / S síncrona / bloqueadora, HAGA ESO . Si su aplicación es susceptible de E / S sin bloqueo y no solo reinventará mal la E / S de bloqueo en el espacio de la aplicación, CONSIDERE pasar a nio en función de las necesidades de rendimiento medidas. ¡Me sorprende cuando busco los resultados de Google para ver cómo pocos recursos citan algún número (reciente) !
También, vea las diapositivas de la presentación de Paul Tyma : La forma antigua es nueva otra vez. Según su trabajo en Google, los números concretos sugieren que la E / S de hilos sincrónicos es bastante escalable en Linux, y considera que "NIO es más rápido" un mito que fue cierto durante un tiempo, pero ya no. Algunos buenos comentarios adicionales aquí en Comet Daily . Cita el siguiente resultado (anecdótico, aún no tiene un enlace sólido a los puntos de referencia, etc.) en NPTL:
En las pruebas, NPTL logró iniciar 100,000 subprocesos en un IA-32 en dos segundos. En comparación, esta prueba bajo un kernel sin NPTL hubiera tomado alrededor de 15 minutos
Si realmente tiene problemas de escalabilidad, es posible que desee ajustar el tamaño de la pila de hilos usando XX:ThreadStackSize . Desde que mencionas a Tomcat ver aquí .
Finalmente, si está obligado y determinado a utilizar E / S sin bloqueo, haga todo lo posible por construir en un marco existente por personas que saben lo que están haciendo . He perdido demasiado de mi propio tiempo intentando obtener una solución de E / S no bloqueadora compleja (por los motivos incorrectos).
Véase también relacionado en SO .
Sajid, veo que estás haciendo cometa (sondeo largo).
Casi nadie habla sobre el problema de ejecutar código de usuario para eventos Comet en NIO. El subproceso NIO que envía eventos Comet llama a su código, si su código no es lo suficientemente bueno, está bloqueando este hilo crítico y otras conexiones Comet DEBEN ESPERAR porque el subproceso 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 programador puede renunciar a su hilo cuando lo desee (no es tan fácil con un enfoque NIO).
El único problema que veo con "Comet síncrono" (basado en IO) es el consumo de memoria de las pilas de hilos.
Yo esperaría que cualquier servidor con suficiente memoria manejara decenas de miles de subprocesos inactivos fácilmente, tal vez cientos de miles.