Reactive applications are non-blocking applications, whose request-serving threads are never left waiting for input/output operations to be resolved: calling an external service, querying a database, accessing a file in the file system, etc. Instead, the request is served, a callback is registered to execute when the requested resource is resolved, and the thread then moves on to another operation. This minimizes waiting times, but also CPU and memory resources, since fewer threads are needed to serve requests. Therefore, a reactive application scales better than an imperative application.
What is the architecture of Spring WebFlux?
Spring MCV
Imperative MVC applications work under the Servlet specification up to version 3.0 and are based on a Thread Pool model: each request is served by a thread created for that purpose.
Each thread serving the request is blocked while it performs input/output operations, such as querying a database. Additionally, any information the thread might need (security context, database transaction status, etc.) is stored in the ThreadLocal structure.
Figure 1: Servlet Dispatcher.
The classic MVC architecture uses a threading model called Thread Per Request:
Figure 2: Thread Per Request.
In this case, a thread will handle the request, and if there is any blocking, such as a request to a database or access to a remote file system, it will be blocked until the resource is available.
Spring WebFlux
Applications developed using Spring WebFlux are applications that follow a Functional Reactive paradigm . Reactive programming is a functional declarative paradigm based on asynchronous data flows and change propagation.
Since requests will be handled by multiple threads, Spring WebFlux doesn't use ThreadLocal, as it's pointless and very expensive. ThreadLocal's replacement is Context.
For request handling, the ServletDispatcher is replaced by DispatcherHandle. For servlet filters, these are replaced by WebFilters .
Additionally, Spring WebFlux incorporates the Reactor project (which also supports RxJava) as a reactive engine. Reactor requires Java 8 to run.
Figure 3: Servlet Dispatcher.
The threading model used by Spring WebFlux is called Event Loop and works as follows:
Figure 4: Event Loop.
In this model , there is an event loop for each logical CPU core. The idea is that each request becomes an event, which is processed sequentially. Processing consists of registering a callback and returning immediately. When the input/output operation is completed, the callback is executed, and the response is returned to the original caller. This model is implemented in servers such as Netty, Node.js, or Nginx.
MVC vs WebFlux
WebFlux-based systems scale much better and maintain response times by better handling the workload. To demonstrate this, a simple test was performed:
Two REST service versions are created, each retrieving 1,300 records from an H2 in-memory database without any filtering or sorting. The test parameters are:
- A CPU with 8 logical cores and a frequency of 2.42 GHz.
- A 32GB RAM at 3200MHz.
- 500 concurrent users attacking Rest services to obtain all records (findAll).
- 0 iterations. A total of 5,000 requests were processed.
Figure 5: Imperative vs Reactive.
The metrics obtained are:
ImperativeServiceApplication (left):
- Memory peaks of 415 Mb.
- More than 100 Strands created.
- CPU spikes exceeding 50% capacity.
- 13,065 classes loaded.
ReactiveServiceApplication (right):
- Memory peaks of 310 Mb.
- Less than 40 Strands created.
- CPU peaks below 15% of capacity.
- 10,847 classes loaded.
These metrics allow reactive systems to carry more load than imperative ones.
Key Takeaways from Using Spring Webflux
- Spring WebFlux presents better performance parameters, as long as the data input/output has a certain latency.
- Reactive programming has a steep learning curve, as it involves a paradigm shift.
- Spring WebFlux and Spring MVC can be used together, although much of the capabilities of WebFlux are lost, so a 100% reactive approach should be adopted.
Since WebFlux requires non-blocking I/O operations, there is still much work to be done, as not all relational database drivers are adapted to this paradigm.
WebFlux also breaks with the classic servlet specification (it supports servlet specification 3.1+) so modules like Spring Security are affected and require different configurations depending on whether an imperative or reactive approach is used.
In short: WebFlux is a good bet for implementing resilient, elastic and fault-tolerant systems, but it requires starting a bit from scratch at the technological level , because although it is still Java and Spring, the way of doing things has changed.
Want to know more about Hunters?
At Altia, we've designed several programs to help people finishing their degree or recent graduates get started in the IT sector, leveraging their talent and passion for technology. One of these programs is Hunters : people who are trendsetters, have an innovative spirit, and contribute to anticipating future challenges.
Being part of Hunters means being part of a cross-functional group with the ability to generate and transfer knowledge.
José Luis Antón Bueso - Solution Architect at Altia
