Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-15584

High percent of failures (timeout) under load from server-side WebClient requests

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: 5.0 RC1, 5.0 RC2, 5.0 RC3
    • Fix Version/s: 5.0 RC4
    • Component/s: None
    • Labels:
    • Last commented by a User:
      false

      Description

      I just test by sample PoC project some blocking / non blocking solutions in simple common scenario.

      Scenario:

      • There are rest blocking endpoint which is quite slow - each request tooks 200 ms.
      • There are other - client application, which call this slow endpoint.
        I have tested current (blocking) Spring boot client (tomcat), Spring Boot 2.0 (netty) with WebFlux - WebClient, Ratpack and Lagom. In each cases I have stressed client application by gatling test simple scenario (100-1000 users / second).

      I have tested ratpack and lagom as reference non blocking io servers to compare results to spring boot (blocking and non blocking).

      In all cases i have results as expected, except spring boot 2.0 test. Its working only for small load levels but even then with high latency. If load level rises up - all requests are time outed.
      (see attachments)

      WebClient usage :

      @RestController
      public class NonBlockingClientController {
          private WebClient client = WebClient.create("http://localhost:9000");
       
          @GetMapping("/client")
          public Mono<String> getData() {
              return client.get()
                      .uri("/routing")
                      .accept(TEXT_PLAIN)
                      .exchange().timeout(Duration.ofSeconds(30))
                      .flatMap(clientResponse -> clientResponse.bodyToMono(String.class));
          }
      }
      

      I have no idea what goes wrong or current M1 version just working that.

      All sources published at https://github.com/rutkowskij/blocking-non-blocking-poc

      blocking-service - slow blocking endpoint
      non-blocking-client - Spring Boot 2.0M1 and WebClient based client

      I have asked for this problem on

      1. springBoot2.png
        64 kB
      2. springBoot2M2-Netty.png
        67 kB
      3. SpringBoot2-Netty.png
        65 kB
      4. spring-boot2-nonblocking-poc-resources.png
        58 kB
      5. SpringBootRatpack.png
        62 kB
      6. SpringBoot-Tomcat-1000threads.png
        61 kB

        Issue Links

          Activity

          Hide
          bclozel Brian Clozel added a comment -

          Thanks a lot Jakub Rutkowski, this really helps.

          Show
          bclozel Brian Clozel added a comment - Thanks a lot Jakub Rutkowski , this really helps.
          Hide
          rstoya05-aop Rossen Stoyanchev added a comment - - edited

          Note that we ran into some issues with reactor-netty not being fully up-to-date with the latest reactor-core. This was just fixed and it might have impacted the testing. We can also give it another try on our side as well.

          Show
          rstoya05-aop Rossen Stoyanchev added a comment - - edited Note that we ran into some issues with reactor-netty not being fully up-to-date with the latest reactor-core. This was just fixed and it might have impacted the testing. We can also give it another try on our side as well.
          Hide
          rstoya05-aop Rossen Stoyanchev added a comment -

          Using the latest snapshot in non-blocking-client and running the performance test, I no longer get any errors.

          Show
          rstoya05-aop Rossen Stoyanchev added a comment - Using the latest snapshot in non-blocking-client and running the performance test, I no longer get any errors.
          Hide
          jrutkowski Jakub Rutkowski added a comment -

          I confirm - It looks that everything ok now. (see attachment)

          Show
          jrutkowski Jakub Rutkowski added a comment - I confirm - It looks that everything ok now. (see attachment)
          Hide
          bclozel Brian Clozel added a comment -

          Nice! I'm closing this issue now - we can still improve performance overall, but this particular problem is now gone.

          Don't hesitate to keep an eye on your benchmarks and let us know - this is really useful.
          Thanks Jakub Rutkowski for all the hard work.

          Show
          bclozel Brian Clozel added a comment - Nice! I'm closing this issue now - we can still improve performance overall, but this particular problem is now gone. Don't hesitate to keep an eye on your benchmarks and let us know - this is really useful. Thanks Jakub Rutkowski for all the hard work.

            People

            • Assignee:
              bclozel Brian Clozel
              Reporter:
              jrutkowski Jakub Rutkowski
              Last updater:
              St├ęphane Nicoll
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                10 weeks, 2 days ago