Is Spring WebFlux a Myth?

Does it really outperform Spring Servlet? Let’s find out the truth

Photo by Boris Stefanik on Unsplash

The way how to build a high performance system is always an intriguing topic for developers. Many people in the industry advocate the paradigm of non-blocking programming, saying that application based on non-blocking programming makes use of resources more efficiently and achieves higher performance compared with traditional imperative programming which is a blocking technology.

Numerous articles explain the benefits of non-blocking programming, it seems to be a superior and future-proof solution. However, I’m not convinced without having the first hand experience to prove it. To find out the truth, I built the same Java application using 2 different frameworks — Spring WebFlux (non-blocking) and Spring Servlet (blocking), then ran a series of experiments in order to compare the system performance between the 2 implementations. Surprisingly, the findings show that non-blocking programming is not always better than the blocking one in certain environment settings.

In this article, you will learn the truth about Spring WebFlux. I will share with you the details of my experiments and the analysis of the performance test results.

What is blocking and non-blocking?

Back to the basics. What is blocking? In traditional computer programming, each line of program code is a synchronous instruction execution. In other words, machines run program logic one by one and the next line of code is not executed until the current instruction is completely executed.

Such systems implemented using blocking programming normally perform really well. However, system threads get stuck if the execution of any process takes time to be completed, resulting in system crashes if the situation worsens.

Thread based blocking process

On the contrary, non-blocking programming implements program logic in a publish-subscribe pattern. The main program flow runs the process and subscribes to the result. Instead of being “blocked” by the current process execution, the main program continues the…