Does the use of Spring Webflux's WebClient in a blocking application design cause a larger use of resources than RestTemplate

Question

I am working on several spring-boot applications which have the traditional pattern of thread-per-request. We are using Spring-boot-webflux to acquire WebClient to perform our RESTful integration between the applications. Hence our application design requires that we block the publisher right after receiving a response.

Recently, we've been discussing whether we are unnecessarily spending resources using a reactive module in our otherwise blocking application design. As I've understood it, WebClient makes use of the event loop by assigning a worker thread to perform the reactive actions in the event loop. So using webclient with .block() would sleep the original thread while assigning another thread to perform the http-request. Compared to the alternative RestTemplate, it seems like WebClient would spend additional resources by using the event loop.

Is it correct that partially introducing spring-webflux in this way leads to additional spent resources while not yielding any positive contribution to performance, neither single threaded and concurrent? We are not expecting to ever upgrade our current stack to be fully reactive, so the argument of gradually upgrading does not apply.

Answer 1

According to official Spring documentation for RestTemplate it's in the maintenance mode and probably will not be supported in future versions.

As of 5.0 this class is in maintenance mode, with only minor requests for changes and bugs to be accepted going forward. Please, consider using the org.springframework.web.reactive.client.WebClient which has a more modern API and supports sync, async, and streaming scenarios

As for system resources, it really depends on your use case and I would recommend to run some performance tests, but it seems that for low workloads using blocking client could have a better performance owning to a dedicated thread per connection. As load increases, the NIO clients tend to perform better.

Update - Reactive API vs Http Client

It's important to understand the difference between Reactive API (Project Reactor) and http client. Although WebClient uses Reactive API it doesn't add any additional concurrently until we explicitly use operators like flatMap or delay that could schedule execution on different thread pools. If we just use

webClient
  .get()
  .uri("<endpoint>")
  .retrieve()
  .bodyToMono(String.class)
  .block()

the code will be executed on the caller thread that is the same as for blocking client.

If we enable debug logging for this code, we will see that WebClient code is executed on the caller thread but for network operations execution will be switched to reactor-http-nio-... thread.

The main difference is that internally WebClient uses asynchronous client based on non-blocking IO (NIO). These clients use Reactor pattern (event loop) to maintain a separate thread pool(s) which allow you to handle a large number of concurrent connections.

The purpose of I/O reactors is to react to I/O events and to dispatch event notifications to individual I/O sessions. The main idea of I/O reactor pattern is to break away from the one thread per connection model imposed by the classic blocking I/O model.

By default, Reactor Netty is used but you could consider Jetty Rective Http Client, Apache HttpComponents (async) or even AWS Common Runtime (CRT) Http Client if you create required adapter (not sure it already exists).

In general, you can see the trend across the industry to use async I/O (NIO) because they are more resource efficient for applications under high load.

In addition, to handle resource efficiently the whole flow must be async. By using block() we are implicitly reintroducing thread-per-connection approach that will eliminate most of the benefits of the NIO. At the same time using WebClient with block() could be considered as a first step for migration to the fully reactive application.

Answer 2

Great question.

Last week we considered migrating from resttemplate to webclient. This week, I start testing the performance between the blocking webclient and the resttemplate, to my surprise, the resttemplate performed better in scenarios where the response payloads were large. The difference was considerably large, with the resttemplate taking less than half the time to respond and using fewer resources.

I'm still carrying out the performance tests, now I started the tests with a wider range of users for request.

The application is mvc and is using spring 5.13.19 and spring boot 2.6.7.

For perfomance testing I'm using jmeter and for health check visualvm/jconsole

Answer 3

You did not properly close and open PHP tag.
From your code.

function insert_scode() {
 echo do_shortcode( '[products limit="4" columns="4" products ids="231,230,123,118"]');
 <div class="scinsert" >

You just call to HTML without close the PHP tag ?>. This should showing the errors.

To fix this, close the PHP tag before send out HTML.

// I assume that you already have PHP open tag <?php.
function insert_scode() {
 echo do_shortcode( '[products limit="4" columns="4" products ids="231,230,123,118"]');
?>
 <div class="scinsert" >
  <?php echo $output; ?>
</div>
   <script>
      <html>
<head>
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
       </head>
   </html>
</script>
<?php
}
add_action( 'get_footer', 'insert_scode', 10 );