java - que - Arquitectura del conector Tomcat, grupos de subprocesos y servlets asíncronos

servlets java

Question

Me gustaría entender el modelo de rosca de Tomcat para conectores BIO y NIO. Me refiero a la documentación oficial de Tomcat 7 para los conectores que se pueden encontrar here . Basado en eso, esto es lo que tengo en duda:

• acceptorThread (s) : Este es un único o como máximo 2 hilos (como se menciona en el documento), que es responsable solo de aceptar las conexiones entrantes. Esto se puede configurar usando acceptorThreadCount , y se sugiere que se pueden usar más de dos para una máquina de varias CPU:
  • Por qué es esto ?
  • ¿Implica esto que la cantidad de conexiones abiertas simultáneas se amplía con el número de CPU frente a la cantidad de descriptores de archivos abiertos permitidos en el sistema del servidor?
• maxConnections (s) :
  • ¿Cuál es la relación entre esta configuración y acceptCount y la cantidad de descriptores de archivos abiertos en el sistema?
  • ¿Por qué el valor predeterminado para esto es mucho más alto para el conector NIO ( 10000 ) que para el BIO ( = maxThreads )?
• acceptCount : esta es la cola para las solicitudes cuando todos los hilos de procesamiento de solicitudes están ocupados.
  • Cuando las solicitudes se colocan en esta cola, ¿se le asigna un descriptor de archivo también? ¿O solo cuando se procesa activamente una solicitud, consume un descriptor de archivo?
• subprocesos de procesamiento de solicitud : el número de subprocesos en este grupo está configurado por los atributos maxThreads y minSpareThreads .
  • ¿Cuál es la relación entre este grupo de subprocesos y el acceptorThreads ? ¿El (los) hilo (s) acepto (s) genera (n) los hilos en este conjunto?
  • Según tengo entendido, el modelo NIO es más eficiente con los hilos de procesamiento de solicitud que el modelo BIO. ¿Cómo logra esta eficiencia?
  • Como he leído en varias fuentes, los hilos en el modelo NIO siguen el paradigma de hilo por solicitud frente al hilo por paradigma de conexión del modelo BIO. Además, en el modelo de conector de NIO, el procesamiento de solicitud real se delega en un subproceso diferente de la aplicación supervisada, mientras que el subproceso de procesamiento de solicitud del servidor se devuelve al grupo de subprocesos sin cargo para aceptar más conexiones. Entonces, ¿esto implica que el beneficio del modelo NIO solo será aparente si las conexiones al servidor son de naturaleza HTTP Keep-Alive o si la aplicación está utilizando la función de procesamiento asíncrono de Servlet 3.0 ?
• Servlet 3.0 :
  • Al usar Servlet 3.0, ¿cuál debería ser el tamaño del conjunto de subprocesos de servlet de la aplicación (en relación con el tamaño del grupo de subprocesos del conector) para lograr una eficacia óptima?
  • Al usar el modelo BIO y esto en conjunto, ¿habrá alguna diferencia en cuanto a cómo se procesan las solicitudes (dado que los hilos del conector seguirán usando el hilo por modelo de conexión )?

Tenga en cuenta: Toda la discusión con respecto a Tomcat 7.

Answer 1

• acceptorThread (s) : Este es un único o como máximo 2 hilos (como se menciona en el documento), que es responsable solo de aceptar las conexiones entrantes. Esto se puede configurar usando acceptorThreadCount, y se sugiere que se pueden usar más de dos para una máquina de varias CPU:

  Por qué es esto ?

La aceptación de conexiones es una operación de muy bajo costo, por lo que no tiene sentido dedicar más de un hilo a esta tarea.

Does this imply that the number of simultaneous open connections
scales with the number of cpus versus the number of open file descriptors
allowed on the server system ?

No, no porque es una operación de muy bajo costo en términos de CPU. En cuanto a los descriptores de archivos, cada conexión aceptada va a utilizar un descriptor de archivo, por lo que la cantidad máxima de conexiones que el servidor puede aceptar está limitada por la cantidad de descriptores de archivos disponibles.

• maxConnections (s) :

  ¿Cuál es la relación entre esta configuración y acceptCount y la cantidad de descriptores de archivos abiertos en el sistema?

maxConnections no puede ser mayor el número de descriptores de archivos abiertos en el sistema. Tenga en cuenta que otros procesos también usan descriptores de archivos, por lo que puede ser conservador con maxConnections en lo que respecta a los descriptores de archivos disponibles, digamos maxConnections <file descriptors / 2.

Why is the default value for this so much higher for the NIO connector
( 10000 ) than for the BIO ( = maxThreads ) ?

Esto se debe a que en NIO, una sola maneja todo IO, y en BIO, el servidor necesita crear / usar una conexión de hilos por conexión separada.

• acceptCount : esta es la cola para las solicitudes cuando todos los hilos de procesamiento de solicitudes están ocupados.

  Cuando las solicitudes se colocan en esta cola, ¿se le asigna un descriptor de archivo también?

Sí, es correcto, se acepta la solicitud de conexión pero el servidor aún no está listo para servir solicitudes, por lo que la conexión se coloca en la cola. Esto se hace para evitar que TCP / stack agote las solicitudes de conexión que pueden parecer un servidor inactivo desde el punto de vista del cliente. En otras palabras, el servidor dice ''Estoy aquí y procesaré su solicitud una vez que tenga los recursos para hacerlo''.

¿O solo cuando se procesa activamente una solicitud, consume un descriptor de archivo?

Nop.

Espero que esto ayude.

Saludos,

Slava Imeshev