¿Cómo utilizar ProtocolDecoder de mina para analizar mensajes websocket?
El foco de la falla de rendimiento aquí es que cuando SelectionKey.OP_READ ready OP_READ ready está listo en el canal, 1. el hilo de selección leerá los datos y luego los enviará al controlador de la aplicación, 2. O ¿Se acaba de distribuir y el hilo del controlador es responsable de la lectura y el procesamiento?
mina, xsocket es 1. grizzly-nio-framework es 2.
Si bien leer el búfer de un canal es una buena idea, no es lo único que puedes hacer.
Si bien la lectura de bytes en el búfer de un canal es rápida, si la ampliamos, el efecto de esta respuesta retardada cuando nos conectamos a canales del orden de decenas de miles o más se volverá más obvio.
MINA:
Para todas las claves seleccionadas
{
lea los datos y luego activeMessageReceived.
}
xSocket:
Para todas las claves seleccionadas
{
leer datos, agréguelos a readQueue y luego realiceOnData.
}
Entre ellos, Mina no usa el grupo de subprocesos en fireMessageReceived para messageReceived, por lo que la aplicación debe asignarlo en handler.messageReceived. El performOnData de xsocket se asigna a threadpool[WorkerPool] de forma predeterminada. WorkerPool resuelve el problema de que los subprocesos en el grupo de subprocesos no pueden llenar el máximo (igual que lo hace tomcat6), pero su mecanismo de programación aún no es lo suficientemente flexible.
Grizzly:
para todas las claves seleccionadas
{
[NIOContext---filterChain.execute-->our filter.execute] <------ejecutar en DefaultThreadPool
}
DefaultThreadPool de grizzly casi reescribe el grupo de subprocesos concurrentes de java util y usa su propio LinkedTransferQueue, pero también carece de un mecanismo de programación flexible específico para Hilos en la piscina.
El siguiente es el análisis del código fuente de MINA, xSocket y Grizzly:
Tome Apache MINA (código fuente de mina-2.0.X-M6 como ejemplo), MINA-2.0. X El código fuente de -M6 es: