Defining the maximum number of concurrent users for a Spring Reactive Web application on a Netty Server

user_1933098 0
Viewed 1193

Spring Webflux, using project Reactor is very promising in terms of using your resources in a more efficient way. It's far from obvious how to calculate the resources required to support a certain number of users, however.

When building a standard web application (not Reactive) which will run on a Tomcat, you can simply define the number of webthreads required to support your users. This does not seem to count for Spring Reactive Web applications, however. A small number of threads is used, and less memory is used, but where in the past you could just define "X webthreads available per server" this doesn't seem possible to do. Making our sysops and devops friends a bit unhappy.

What's a solution for this issue? Because it's hard to "sell" a Reactive solution, when it's one that's not very deterministic when it could break down.

project-reactor spring-webflux netty
1 Answers

I understand server threads can be a metric like any other to measure the amount of resources you want to allocate to a server. This works on a "one request per thread model", but also has its own limits. How do you measure efficiency with:

  • persistent connections like Server Sent Events?
  • "slow clients", reading HTTP response really slowly?
  • threads waiting for blocking I/O (doing a remote REST call for example)

In those cases, you're using your server threads but your server resources aren't really used. You can then increase that number more and more, until your server is more busy context switching between threads than doing actual work.

In the end you're using that metric to express "this is the number of users a server instance can talk to while still having a reasonable latency for our use case".

Depending on your use case, a Spring MVC app may perform better than a WebFlux one: for example, latency and slow clients aren't a real issue in your app. Or a WebFlux app could be more predictive than a Spring MVC one: your app scales well under load and latency doesn't suddenly explodes when it's reaching a certain level of concurrency.

TL;DR

Nothing beats benchmarking your application with real traffic and looking at the 95th percentile latency.

user_229820
Related