java - socket - ¿Cuáles son las alternativas de Netty para redes de alto rendimiento?

socket javascript

Question

Estoy en el proceso de elegir una biblioteca de red para implementar un sistema cliente / servidor que no puede ahorrar ningún microsegundo. Implementará su propio protocolo para enviar y recibir mensajes. Estoy buscando un buen marco NIO que me permita desarrollar fácilmente el servidor y el cliente, sin tener que preocuparme demasiado por los detalles del selector de bajo nivel. Todos me recomiendan Netty, pero me gustaría experimentar con otras 2 o 3 alternativas antes de comprometer a mi equipo con un marco. Una cosa que no me gustó mucho de Netty es cómo maneja los ByteBuffers con su propia implementación y conteo de referencias de ByteBuf. ¿Alguien puede compartir sus pensamientos y alternativas?

Answer 1

Esto es asumiendo que realmente quieres o guardar cada microsegundo. La mayoría de las aplicaciones no tienen tales requisitos de strick.

Si desea guardar microsegundos, querrá usar NIO sin bloqueo, ocupado, en espera, para las hebras de las CPU dedicadas. Esto no se escala bien ya que necesita tener suficiente CPU, pero minimiza la latencia para el manejo de IO. Le sugiero que también enlace las CPU aisladas para minimizar el jitter.

Usted querrá evitar el uso de selectores ya que bloquean y / o crean un poco de basura agregando a las pausas de GC.

Además, para minimizar la latencia, querrá usar un adaptador de red de bypass del kernel de baja latencia, como Solarflare.

Querrá utilizar un analizador de inserción para que los mensajes largos puedan decodificarse / analizarse a medida que se descargan. es decir, no querrá esperar hasta que se reciban todos los mensajes antes de comenzar.

El uso de estos trucos en combinación puede ahorrar de 10 a 30 microsegundos en cada solicitud o evento entrante.

Netty es una mejor solución para la escalabilidad, es decir, mayor rendimiento neto, pero a un pequeño costo de latencia, al igual que la mayoría de los marcos que se basan en servicios web de soporte donde los retrasos de milisegundos son tolerables.

Answer 2

Hemos desarrollado una biblioteca de redes NIO que funciona en menos de 2 microsegundos en bucle invertido sin producir ningún tipo de basura para el GC. Como lo mencionó Peter Lawrey, el selector JDK nativo produce mucha basura, pero hemos solucionado todas estas fugas de basura al implementar nuestro propio selector de epoll. La espera del hilo del selector es excelente para la latencia, pero debe haber un equilibrio para no quemar el chip o consumir mucha energía. Nuestra implementación de selector utiliza trucos de bajo nivel para implementar un tipo de modo de ahorro de energía que cuida ese equilibrio.

Además de CoralReactor , también puedes echar un vistazo a Grizzly y Mina , pero todavía no hemos jugado con estos marcos.

Para algunas pruebas de rendimiento de Netty TCP, puede echar un vistazo here .

Answer 3

Si está de acuerdo con usar al menos algo de Scala, Spray es una excelente alternativa a Netty. A largo plazo, el marco de Play tiene, por ejemplo, la intención de migrar de Netty a Spray. Spray ofrece diferentes niveles de abstracciones de TCP. Esos son:

1. Nivel de trozo
2. Nivel de solicitud (HttpRequest / HttpResponse)
3. Nivel de objeto recortado

Cuanto más se profundiza en la pila, más bruta es la información entregada. En la API de nivel de trozos, te acercas bastante a los buffers de bytes originales. Nunca usé este bajo nivel de abstracción, pero escuché cosas buenas.

Spray se construye sobre Akka IO, que nuevamente se construye sobre Java NIO. Toda la funcionalidad envuelve las abstracciones de Actor, lo que facilita la creación de aplicaciones paralelas utilizando Spray. Creo que un servidor de chat sería un caso de uso perfecto. Como Akka ofrece una API de Java, debería poder usar Spray con la mayoría de estas API. Sin embargo, es probable que necesites leer algunas fuentes de Scala de vez en cuando. Eventualmente, Spray se fusionará completamente con Akka.

Edición: Cita del sitio web de Spray: "El spray ya no se mantiene y ha sido reemplazado por Akka HTTP . Playframework comenzó de manera experimental con el respaldo del servidor Akka HTTP a partir de Play 2.4.X. En las versiones Play 2.6.X , el juego migró completamente a Akka Backend del servidor HTTP.