Reactive programming model introduces a new prospective of programming. A good question is: Do I really need it? What’s wrong with model used today?
In this post, I’ll try to explain why this is an important switching and what this means for developers.
What’s Reactive Programming Model? Briefly, because it’d need worth an entire blog to explain in detail what features brings to us, I’d summarize the model in these keywords concept:
- Functional programming Model;
The core idea is to cut off the Latency time using asynchronicity and avoid blocking resources adopting a Functional instead of imperative programming model as usual.
Easy not? The concept is better expressed in the Reactive Manifesto and the teams (Reactive project and Spring) have made a great job to achieve this aim, and I warmly recommend to have a look at these slides:
and relative video:
Rossen, in his presentation, introduces the Reactive Model and explains the difference between the traditional Async and Reactive model specially for the blocking aspect of the last.
The big change is inside the Thread management; normally, you can see the Thread management during an application running as following figure:
The Server receives the request from a Client and execute the process sticking the thread to the process. During this process the request is delay by the latency of the I/O resources and/or the execution of the business block. Anyway, the thread is locked.
Try thinking something more flexible, the result could be this:
In this figure the process is not sticked at the request but, a worker process, assigned the thread at the process when, and only when, it really needs to do something and/or the I/O resources are available to process the request.
One note before moving on; writing code using reactive programming model doesn’t necessary mean writing code which run faster; the concept is to write code which will be able to be horizontal scalable in the future in order to satisfy the bigger number of request.
At this point, I came across this discussion at stackoverflow some days ago.
Brilliant question from Jakub who wondered why using Reactive programming model the access to a slow resource takes more response time than a classic approach with RestTemplate object from Spring 4.
There’s a case open for this issue at https://jira.spring.io/browse/SPR-15584. Anyway, I’d bid you to download the source code from gitHub (https://github.com/rutkowskij/blocking-non-blocking-poc) and make a test changing the number of max thread used in the blocking client to 4.
That’s because, this model, “it’s suitable for event-loop style processing with a small number of threads” as expressed in this post
Now running a JMeter test. These are my results for a blocking client (using RestTemplate).
Number of User: 40
Avg Time: 1893 ms
And these are for non blocking client (using WebClient).
Number of User: 40
Avg Time: 432 ms
Increasing the number of threads for the first test we get a better result but, this is the point; we can get better result with less resources as memory, cpu, threads with WebClient than RestTemplate.
That’s all. In the future articles, I’d like to illustrate other aspects of the Reactive programming model (Stream, back-pressure, etc..).
I hope to have made interest on the topic and, maybe, clarify some aspects of this model.