Spring MVC vs WebFlux: a dónde van realmente tus hilos

Spring MVC le da un hilo a cada petición. Eso funciona bien con poco tráfico. Deja de funcionar cuando mil usuarios golpean tu API al mismo tiempo.

Un hilo, de principio a fin

En Spring MVC, cada petición HTTP recibe un hilo del thread pool del contenedor de servlets. A esto se le conoce como el modelo thread-per-request.

Ese hilo se mantiene ocupado durante toda la petición. Controlador, servicio, repositorio, base de datos, respuesta. No vuelve al pool hasta que la petición termina.

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    return userService.findById(id); // el hilo espera aquí hasta que todo termine
}

Más usuarios significa más hilos

Más peticiones concurrentes significa más hilos. Pero los hilos no son gratis.

Cada hilo consume RAM. Y la CPU gasta tiempo en el context switching, decidiendo qué hilo ejecutar después. Si agregas demasiados hilos, el sistema termina gastando más tiempo cambiando entre ellos que haciendo trabajo real.

El costo real es esperar, no trabajar

La mayor parte del tiempo de un hilo en este modelo no se gasta calculando. Se gasta esperando: una consulta a la base de datos, una llamada a una API externa.

Digamos que una consulta tarda 4 segundos. Ese hilo queda bloqueado esos 4 segundos, sin hacer nada, solo ocupando un espacio en el pool.

WebFlux: menos hilos, ninguno esperando

Spring WebFlux, basado en Project Reactor y que se ejecuta en Netty de forma predeterminada, reemplaza el thread-per-request con un event loop. Un número pequeño de hilos se encarga de todo.

Cuando un hilo necesita hacer I/O, como una llamada a la base de datos, envía la petición y regresa de inmediato. No espera la respuesta. El sistema operativo le avisa al event loop cuando los datos están listos (en Linux, esto usa epoll), y el hilo retoma la tarea justo donde la dejó.

Un solo hilo puede manejar miles de peticiones en curso sin bloquearse en ninguna en particular.

@GetMapping("/users/{id}")
public Mono<User> getUser(@PathVariable Long id) {
    return userService.findById(id); // devuelve el resultado de inmediato, el hilo pasa a realizar otra tarea
}

La misma forma, el mismo nombre de método. El tipo que se retorna es lo que lo cambia todo.

Esto se me hizo familiar. Si has trabajado con JavaScript, en el navegador o en Node, ya conoces este patrón: un hilo, I/O no bloqueante, y un callback (o una promesa) que retoma la ejecución cuando los datos están listos. Es la misma idea. La diferencia está en la escala. JavaScript corre sobre un solo hilo de event loop. WebFlux corre varios, usualmente uno por núcleo de CPU, así que es más parecido a tener varios event loops pequeños al estilo Node trabajando en paralelo, en vez de uno solo.

Backpressure: el cliente marca el ritmo

WebFlux también cambia cómo transmites datos. En vez de enviar toda la respuesta de una vez, el servidor abre un canal y empuja pequeños fragmentos a medida que están listos.

El cliente puede indicarle al servidor cuántos datos quiere recibir a la vez. A esto se le llama backpressure. Es útil para todo lo que sigue generando datos después de la primera respuesta: feeds de bolsa en tiempo real, actualizaciones de ubicación en tiempo real, ese tipo de flujo.

El truco: toda la cadena tiene que ser no bloqueante

La mayoría de las introducciones a WebFlux se saltan esta parte. Solo vale la pena si todo tu stack es no bloqueante.

Tu driver de base de datos tiene que ser reactivo: R2DBC, no JDBC. Tu cliente HTTP tiene que ser WebClient, no RestTemplate. El tipo de retorno lo delata:

// JDBC: bloqueante, retorna el valor directamente
public User findById(Long id) {
    return jdbcTemplate.queryForObject(SQL, mapper, id);
}
 
// R2DBC: no bloqueante, retorna un tipo reactivo
public Mono<User> findById(Long id) {
    return databaseClient.sql(SQL)
        .bind("id", id)
        .map(mapper)
        .one();
}

Si usas WebFlux pero mantienes una sola llamada bloqueante a JDBC, bloqueas uno de los pocos hilos del event loop, normalmente tantos como núcleos tiene tu CPU. En MVC, perder un hilo de doscientos (el tamaño por defecto del pool de Tomcat en Spring Boot) casi no se nota. En WebFlux, perder uno de esos pocos es un problema mucho más grande.

Antes de migrar, revisa cada capa en busca de una llamada bloqueante. Basta con una sola para anular el beneficio.

Comments