network - Netty 4-EventLoopGroup-EventLoop-EventExecutor-Afinidad de subprocesos

netty-http

Question

Estoy estudiando el código Netty 4.0.0.Alpha5 para averiguar cómo se manejan los hilos. También leí la introducción al nuevo modelo de subprocesamiento de Netty 4 en http://netty.io/wiki/new-and-noteworthy-in-4.0.html#wiki-h2-34 .

Como yo lo entiendo, los objetivos son:

• Afinidad de hilos, pegue un canal a un solo hilo (EventLoop). Supongo que se adoptó este enfoque para reducir las fallas de caché y mejorar la situación en el hardware NUMA.

Entonces, me pregunto si mi interpretación es correcta o no. Y si estoy en lo cierto, entonces surge la siguiente pregunta:

• Es posible que tener un ChannelHandler de larga duración (por ejemplo, una operación de base de datos) en ChannelPipeline bloquee el EventLoop (Thread) y, por lo tanto, bloquee todos los otros canales asignados al mismo EventLoop (Thread). ¿Es esta interpretación cierta?
• Tratando de evitar ese problema, podría usar un EventExecutor para el ChannelHandler de larga duración, pero de acuerdo con la documentación (vea el enlace de arriba), un canal está nuevamente pegado a un solo hilo dentro de su EventExectuor y, por lo tanto, podría bloquear de nuevo a otros canales a los que se asigna el mismo Hilo (dentro del EventExecutor). ¿Me perdí algo o es esto cierto?

Solo intento comprender por qué las cosas son como son y obtener información sobre las intenciones de diseño de Netty 4.

Answer 1

Tus dos puntos también son ciertos con Netty 3.

Netty 3 tenía un concepto de hilos de jefe y trabajador. Un subproceso principal era responsable de aceptar nuevas conexiones, que luego descargaría en un subproceso de trabajo. La cantidad de subprocesos de trabajo se pudo configurar al crear su NioServerSocketChannelFactory .

Ahora Netty 4 ha reemplazado estos subprocesos de jefe y de trabajo por el bucle de evento principal y el bucle de evento secundario respectivamente. Pero la idea central sigue siendo la misma: para deshacerse del modelo de hilo por conexión , debe asignar más de una conexión a un hilo.
Por lo tanto, cuando cree un servidor, habrá un grupo fijo de N hilos dedicados al manejo de conexiones. Si el número de conexiones es inferior a N, no habrá más de una conexión por subproceso. Por otro lado, si tiene más de N conexiones, algunos subprocesos administrarán más de una conexión. Esto se hace en forma de round-robin, echa un vistazo a MultithreadEventExecutorGroup.next()

Answer 2

Fiel a las dos preguntas. Al asignar un controlador a un grupo de eventos que no son de E / S, puede evitar que un subproceso de E / S se bloquee por operaciones de larga ejecución, como el acceso a la base de datos. Puede especificar un EventExecutorGroup con un tamaño grande dependiendo de lo que haga el controlador. No es muy diferente de lo que suele hacer el conjunto de hilos. Si el grupo de subprocesos está ocupado, cualquier intento de ejecutar una tarea de larga ejecución se pondrá en cola.