1

I am trying to evaluate Spring WebFlux and advantages of reactive processing. To do so I have implemented tiny project with jetty server setup that exposes same endpoint over sync jersey, async jersey and spring web-flux.

Repository can be found here https://github.com/aakhmerov/nio-test

As far as I can see current implementation is not faster then synchronous processing implemented over jersey. Which makes me think that I have made some mistake in setup.

Flux setup is done over annotations through classes

com.aakhmerov.test.flux.FluxConfig:

@Configuration
@ComponentScan(basePackages = "com.aakhmerov.test.flux")
@EnableWebFlux
public class FluxConfig {
}

com.aakhmerov.test.flux.FluxStatusRestService:

@RestController
@RequestMapping(value = "/flux/status")
public class FluxStatusRestService {

  @Autowired
  private StatusCheckingService statusCheckingService;

  @GetMapping("/connection")
  public Mono<ConnectionStatusDto> getConnectionStatus() {
    ConnectionStatusDto result = 
      statusCheckingService.getConnectionStatus();
    return Mono.just(result);
  }
}

which is then wrapped into servlet and plugged into embedded jetty server. The questin is if it's using async boundry out of the box at all or some extra configuration is required.

Here are sample results of a test run:

Endpoint: [http://localhost:8090/api/status/async/threaded-connection] 
 error count [0] 
 avg duration [3993] ms

Endpoint: [http://localhost:8090/api/status/connection] 
 error count [0] 
 avg duration [4595] ms

Endpoint: [http://localhost:8090/api/status/async/unmanaged-threaded-connection] 
 error count [0] 
 avg duration [2455] ms

Endpoint: [http://localhost:8090/flux/status/connection] 
 error count [0] 
 avg duration [4850] ms

Endpoint: [http://localhost:8090/api/status/async/connection] 
 error count [0] 
 avg duration [1963] ms

I am not claiming this test to be perfect in any sort, but webflux endpoint is way off behind at the moment, which makes me wonder what is going wrong there.

Thank you in advance.

Askar Akhmerov
  • 81
  • 8
  • 2
    I don't know what you expected, but just using reactive streams and non-blocking I/O does not automatically make it run faster. It has benefits for scalability, especially when there's network latency (you won't have to have many blocking threads in your application that are taking up resources), but it's not going to be any faster just because you are doing things asynchronously. – Jesper Jan 03 '18 at 13:08
  • well, I am actually confused how Jersey is managing to gain speed with avg duration [1963] ms. This endpoint is only implemented [here](https://github.com/aakhmerov/nio-test/blob/720b4f49d7e00ab10e7ccb0c845961465e327e72/src/main/java/com/aakhmerov/test/jersey/AsyncStatusRestService.java#L24) and is by far fastest. I would expect something like that to work out of the box with non blocking io. – Askar Akhmerov Jan 05 '18 at 06:33

0 Answers0