Robust Service with Spring Reactive
Hi all, it’s my very first medium article.
I’ll show you why Spring Reactive architecture able gives us a robust service. The robust metric that covered here is how we can handle bigger requests with the same server specification.
Objective
I will perform simple research that compares the two API which builds from Spring web vs Spring web reactive. Both APIs process small load by returning POJO with value success=true and has the same thread delay for 5s.
Then I do the performance test & monitor both APIs using jMeter. I also use jvisualvm to monitor the JVM performance.
I will explain jMeter & jvisualvm usage in the next article.
Variables
Independent variable:
1) Concurrent request amount
Dependent variable:
1) Success rate
2) Maximum API response
3) APIs maximum capability to handle the concurrent request
Controller variable:
1) Laptop specification (HP EliteBook core i7)
2) Java memory allocation (Xms 25M, Xmx 50M)
3) Thread delay = 5s
Hypothesis
The spring reactive web should be able to handle more concurrent requests.
Result
API Minimum Response Comparison
Base on image 1 the reactive system has better API minimum response through various concurrent requests. Both system nearly has the same API response on concurrent request under 600.
But when the concurrent requests keep increasing, the non-reactive has worse minimum API response even the non-reactive got an OOM issue when the concurrent requests touch 700. When the non-reactive system got an OOM you need to restart the system, because the app doesn’t respond to any further request. KABOOM!
API Maximum Response
The API maximum response shows the same result as Image 1. The reactive system has a far better result than non-reactive. The reactive system maximum response is stable around 5s. But the non-reactive system has 16s to 22s response growth through 700 concurrent requests. Of course, non-reactive died on 700+ concurrent requests.
API Error Rate
Image 3 result is still prooving that the reactive system has better performance. It can handle 1000 concurrent requests with a 100% success rate. Non-reactive system cant runs on 700+ concurrent requests.
Conclusion
A reactive architecture allows your service can handle more requests than a non-reactive. With the same server specification, it can process more concurrent requests. Imagine how much you can reduce your server cost.
The reactive system also avoids your service got an OOM error than non-reactive. On 2000 concurrent requests, the reactive system still returns a response although its error rate is high & it doesn’t get an OOM.
If you got an OOM, you need to restart your service. It’s not a robust system at all, because you will lost your customer/client during OOM issue.
Next
In the next article, I will post the comparison with the heavier load. So we can figure the reactive capacity to handle heavier load through concurrent requests.
Appendix
