node - performance java vs go
¿algún beneficio real de usar servlet 3.1 async io? (3)
Async IO puede tener un profundo efecto en el rendimiento en ciertos escenarios. Mi experiencia es principalmente con el equivalente de ASP.NET, pero debería aplicarse aquí también.
Un servlet tiene un número finito de hilos para manejar las solicitudes. Si hay algún tipo de bloqueo IO (una solicitud de red, una consulta de base de datos, etc.), el hilo que maneja la solicitud permanece en uso mientras se queda esperando que se complete el IO. En escenarios de alto volumen, esto puede privar al conjunto de subprocesos y provocar una grave degradación del rendimiento.
Con async IO, IO no bloquea el hilo de solicitud. En cambio, se registra una devolución de llamada y posteriormente se llama cuando se completa el IO. Mientras tanto, el hilo se devuelve al grupo de subprocesos donde puede continuar sirviendo otras solicitudes.
Me pregunto si los contenedores de servlets como Tomcat, Jetty, etc. ya usan nio para leer y escribir datos, ¿es realmente necesario usar setWritelistner y setReadListner en las entradas y salidas de servlet? ¿Hay alguna ganancia de rendimiento adicional?
El beneficio no es directamente 1 sobre "ganancia de rendimiento". El objetivo de estos métodos es evitar que un subproceso de solicitud (en modo asíncrono) se bloquee cuando lee los datos de entrada (POST) o escribe el documento.
Hay un ejemplo en el tutorial de Java EE7: "17.13.1 Lectura de una solicitud HTTP POST grande utilizando E / S sin bloqueo" (enlace actualizado).
Esto es ortogonal al uso de nio de Tomcat bajo las sábanas.
1 - Hay un beneficio de rendimiento indirecto. Cuando es probable que los hilos se bloqueen en E / S de red, una estrategia alternativa para aumentar el rendimiento es aumentar la cantidad de hilos de trabajo. Pero eso aumenta la huella de memoria (entre otras cosas) dando como resultado más "gastos generales".
Tomcat lee los encabezados (y lo hace en un modo no bloqueante para NIO) pero la lectura de cuerpos de solicitud es una preocupación de la aplicación y se realiza con IO de bloqueo (hasta el requisito de Servlet 3.0 de la especificación). Del mismo modo, escribir la respuesta se hace bloqueando IO, ya que también es un requisito de la especificación.
Todo esto cambia con Servlet 3.1.
Es posible que desee ver el hilo de correo electrónico para esto
Debajo del párrafo y el ejemplo de código es de Java EE 7 Recipies se explica el uso de setWritelistner y setReadListner
Para implementar una solución de E / S sin bloqueo, se han agregado nuevas interfaces de programación a ServletInputStream y ServletOutputStream, así como a dos detectores de eventos: ReadListener y WriteListener. Las interfaces ReadListener y WriteListener hacen que el procesamiento de E / S de servlet se realice de forma no bloqueante mediante métodos de devolución de llamada que se invocan cuando el contenido del servlet se puede leer o escribir sin bloquear. Utilice el método ServletInputStream.setReadList ener (ServletInputStream, AsyncContext) para registrar un ReadListener con un ServletInputStream, y use la lectura de E / S ServletInputStream. Método setWriteListener (ServletOutputStream, AsyncContext) para registrar un WriteListener. Las siguientes líneas de código demuestran cómo registrar una implementación de ReadListener con ServletInputStream:
AsyncContext context = request.startAsync();
ServletInputStream input = request.getInputStream();
input.setReadListener(new ReadListenerImpl(input, context));