Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Reactive vs. Synchronous Performance Test with Spring Boot 2.0

DZone's Guide to

Reactive vs. Synchronous Performance Test with Spring Boot 2.0

The author conducts two tests with differing service delay times to measure any difference in performance between reactive and synchronous programming.

Free Resource

xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.

Reactive programming has been steadily gaining awareness over the last few years and searching for the “reactive programming” topic on Google Trends confirms it.

Gartner puts it at the peek of inflated expectations of the hype cycle, but only time can tell what will happen.

I personally believe that it has non-neglectable benefits. It allows developers to take the benefits of asynchronous programming without the added code complexity.

So let's break it down in two topics:

  • Easier asynchronous programming
  • Better performance than synchronous code on high concurrency scenarios

Easier Asynchronous Programming

Let’s see an example of a method that fetches a user from a database, does some conversions, transformations and then displays the results.

The synchronous version look like this:

User user = getUserFromDBSync(id);
user = convertUser(user);
user = processResult(user);
displayResults(user);

Pretty straight forward.


The async version with callbacks has deeply nested code, essentially the “callback hell”.

getUserFromDB(id, user -> {
  convertUser(user, convertedUser -> {
    processResult(convertedUser, processedUser -> {
      displayResults(processedUser);
    });
  });
});


Now the same example with the reactive approach. It is much more readable and maintainable than the async/callback version.

getUserFromDBAsync(id)
  .map(user -> convertUser(user))
  .map(user -> processResult(user))
  .subscribe(user -> displayResults(user));

Performance on High Concurrency Scenarios

On the performance topic, I’ve decided to do a small test to evaluate the performance difference of the reactive versus the synchronous version.

You can get the test project here https://github.com/trincaog/reactivetest

The test setup is:

  • Load testing client (Gatling)
  • Test Service (Spring Boot)
  • External backend service (simulated)

Test Service

The test service simulates a query to an external service (ex: database) which takes some time to return a list of records. For simplification, the test doesn’t send a query to a real database, instead it simulates the response delay.

The synchronous version uses:

  • A Spring Boot 2.0 (2.0.0.RC1) application / Spring MVC framework
  • Embedded Tomcat container with max threads=10.000 (large number to avoid queued requests)
  • Hosted on AWS ECS/Fargate with 256 mCPU / 2GB RAM

NOTE: In a typical environment, having this many threads would lead to DB connection pool exhaustion and queries would start getting queued, thus increasing the response time.

The reactive version uses:

  • A Spring Boot 2.0 (2.0.0.RC1) application / Spring Webflux framework
  • Netty framework
  • Hosted on AWS ECS/Fargate with 256 mCPU / 2GB RAM

Load Testing Client

The following components were used:

  • AWS EC2 t2.small 1vCPU / 2GB RAM
  • Gatling 2.3.0
  • Continuous request loop without any delay between requests
  • 2 configurations of external service: one with 500ms response time; another with 2.000ms response time

Load Test #1: External Service Delay 500ms

Image title

With <=100 concurrent requests, the response times are very similar between the 2 versions.

After 200 concurrent users the synchronous/tomcat version starts deteriorating the response times, while the reactive version with Netty holds-up until 2.000 concurrent users.

Load Test #2: External Service Delay 2.000ms

Image title

This test uses a much slower backing service (4x slower) and the service handles a much larger load. This happens because, although the number of concurrent users are the same, the number of req/sec is 4x lower.

In this test, the synchronous version starts deteriorating with 4-5x the number of concurrent users than the prior 500ms delay test.

If you like this topic, you can also check other posts with interesting performance tests here and here.

Discovering, responding to, and resolving incidents is a complex endeavor. Read this narrative to learn how you can do it quickly and effectively by connecting AppDynamics, Moogsoft and xMatters to create a monitoring toolchain.

Topics:
reactive programming ,spring boot 2 ,gatling ,spring webflux ,aws ecs ,asynchronous ,load testing ,performance

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}