WebFlux y hilos virtuales: comparación a 2000 RPS | Análisis

# WebFlux frente a Hilos Virtuales: Comparación a 2000 Solicitudes por Segundo

Bajo cargas elevadas, la elección entre el modelo reactivo de Spring WebFlux y el nuevo paradigma de hilos virtuales de Project Loom determina el rendimiento y la escalabilidad de las aplicaciones Java. Este estudio presenta los resultados de pruebas de carga para ambos enfoques a 2000 solicitudes por segundo en un proyecto de microservicios de ejemplo.

Arquitectura de Spring WebFlux: Event Loop y E/S No Bloqueante

Spring WebFlux utiliza un modelo de E/S no bloqueante con un event loop. A diferencia del modelo tradicional «una solicitud—un hilo», WebFlux maneja miles de conexiones con un pequeño número de hilos. El principio clave: un hilo no se bloquea esperando E/S; en su lugar, registra interés en un evento (p. ej., «datos llegaron al socket») y pasa a otras tareas.

El componente central es Netty, que WebFlux usa por defecto. Netty gestiona el event loop mediante EventLoopGroup. El número de hilos del event loop se determina con esta fórmula:

int DEFAULT_IO_WORKER_COUNT = Integer.parseInt(System.getProperty(
        ReactorNetty.IO_WORKER_COUNT,
        "" + Math.max(Runtime.getRuntime().availableProcessors(), 4)));

En otras palabras, el número de hilos equivale al número de procesadores disponibles, pero no menos de 4. En un entorno de contenedores, este valor se puede ajustar para que coincida con los recursos asignados.

Cada conexión de red (Channel) está vinculada a un event loop específico (afinidad de canal). Esto asegura ausencia de sobrecarga de sincronización y eficiencia en la caché de CPU. Sin embargo, cualquier operación bloqueante en un event loop detiene el procesamiento para todas las conexiones asociadas a ese loop.

Hilos Virtuales: Cómo Funciona Project Loom

Los hilos virtuales mantienen el modelo «una solicitud—un hilo», pero reducen drásticamente los costos de sobrecarga. Cada solicitud obtiene su propio hilo virtual, que se monta sobre hilos carrier (hilos de plataforma). Los hilos carrier son gestionados por un programador basado en ForkJoinPool.

El número predeterminado de hilos carrier equivale al número de procesadores disponibles. Por ejemplo, en un contenedor con 2 CPUs, habrá 2 hilos carrier capaces de ejecutar miles de hilos virtuales.

El método de creación del programador predeterminado:

private static ForkJoinPool createDefaultScheduler() {
    ForkJoinWorkerThreadFactory factory = pool -> new CarrierThread(pool);
    int parallelism, maxPoolSize, minRunnable;
    String parallelismValue = System.getProperty("jdk.virtualThreadScheduler.parallelism");
    String maxPoolSiz

Ventajas de los hilos virtuales:

• Preserva el estilo de programación imperativa
• Trazas de pila legibles
• Soporte para ThreadLocal
• Simplifica la integración con bibliotecas bloqueantes existentes

Resultados de Pruebas de Carga a 2000 Solicitudes por Segundo

Las pruebas en el proyecto de microservicios de ejemplo revelaron lo siguiente:

• WebFlux mostró un rendimiento estable siempre que no hubiera operaciones bloqueantes en el event loop. Sin embargo, integrar bibliotecas bloqueantes (p. ej., JDBC) requirió descargar esas operaciones a un pool de hilos separado (Schedulers.boundedElastic()), lo que añadió complejidad.
• Los hilos virtuales simplificaron el desarrollo y la depuración mientras ofrecían alto rendimiento. A 2000 solicitudes por segundo, los hilos virtuales en Spring MVC y Tomcat igualaron el throughput de WebFlux, con código familiar para la mayoría de desarrolladores Java.

Un factor crítico para WebFlux fue usar correctamente las cadenas reactivas y evitar llamadas bloqueantes en el event loop. Para los hilos virtuales, ten en cuenta que no abordan operaciones ligadas a CPU: una alta carga de CPU puede llevar a contención por hilos carrier.

Diferencias Críticas y Recomendaciones

Al elegir entre WebFlux y hilos virtuales, considera estos aspectos:

• Tipo de Carga de Trabajo:

- Ambos enfoques destacan en apps ligadas a E/S (espera pesada de E/S)

- Para tareas ligadas a CPU, los hilos virtuales pueden rezagarse debido a contención de hilos carrier

• Ecosistema de Bibliotecas:

- Si tu proyecto depende de bibliotecas bloqueantes (JDBC), los hilos virtuales facilitan la migración

- Para proyectos nuevos que admiten drivers reactivos (R2DBC), WebFlux sigue siendo viable

• Experiencia del Equipo:

- La programación reactiva exige un conocimiento profundo de patrones asíncronos

- Los hilos virtuales permiten un estilo imperativo familiar

Conclusiones Principales

• Rendimiento a 2000 solicitudes por segundo: Ambos manejan la carga, pero los hilos virtuales simplifican el desarrollo al ceñirse al estilo imperativo
• Limitaciones Críticas: Una operación bloqueante en el event loop de WebFlux paraliza todas las solicitudes en ese loop; los hilos virtuales no resuelven problemas ligadas a CPU
• Ecosistema: Adoptar WebFlux implica cambiar bibliotecas bloqueantes por reactivas, lo que puede ser costoso
• Depuración: Las apps reactivas son más difíciles de diagnosticar debido a trazas de pila desordenadas, mientras que los hilos virtuales ofrecen herramientas de perfilado familiares

— Editorial Team