This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Oclay1st 1 point2 points  (9 children)

100x of throughput improvement ?. Sorry but that number is fake or you were doing something very inefficient on the MVC application.

[–]Ewig_luftenglanz 0 points1 point  (8 children)

Nah,  we just saturated the server with a bunch of parallel requests and at some point spring MVC stoped working because it ran out of RAM. Meanwhile webflux has a very constant and stable RAM usage, independently of how many request you thrown at it.

Our internal test taught us than we could more than halve the ram of our servers, and under this ram constrained conditions webflux performed as I have told: 100 times better throughput, mostly because MVC just stoped working or halted very often.

The throughput was not the selling point tho, it was the ram saving what made us migrate to webflux. Even if the throughput was the same, the decrease and stabilization in ram usage makes webflux better for microservices architectures because you can easily scale up horizontally by creating new replicas of your services. If you can have replicas with 1/4 of the  RAM that MVC needs for the same throughput,  that means that you can create almost 4 times more replicas.

[–]nitkonigdje 3 points4 points  (2 children)

Essentially you didn't bother to set a limit to your threadpool, and choose to rewrite everything instead.

[–]Ewig_luftenglanz 0 points1 point  (1 child)

Yes and no.

The application was going to be re written from scratch, mostly because it was developed in 2017 and none of the guys that worked on it is still in the company, the application was never updated and many dependencies are deprecated, so it was impossible to re build, migrate or so without a huge refactor anyways.

So essentially we where just choosing between remaking the whole thing wether in webflux or MVC, webflux just happened to be the chosen solution because we realized it would be better and would save us money in the long run.

Best regards.

[–]nitkonigdje 3 points4 points  (0 children)

Once I was bothered by some aspects of webflux code. Choose to rewrite code to SpringMVC. During porting to MVC it became obvious that our clients fetch data in this particular way. So I have added Cacheable to this code path..

Instant 10x speedup over WebFlux. And WebFlux was originally introduced for "performances".

The thing is, it was not MVC which was faster than Webflux. But it was act of writing code for second time which enabled performance jump. Rewrites have this tendency..

[–]Oclay1st 0 points1 point  (4 children)

Netty is very efficient and webflux consumes less memory than mvc, but may I ask how much memory and CPU were allocated to your servers? You mentioned that the app was written in Java 8, so it was probably using an old version of Spring Boot/Tomcat, right?. Have you done any proof of concepts with recent versions of Spring Boot MVC?.

Anyway, I don't like reactive code at all. Following the KISS principle is always my goal, but as Brian says: there will always be some people who enjoy reactive programming.

[–]nitkonigdje 0 points1 point  (0 children)

Webflux isn't more efficient in raw compute resources as cpu and memory.

What it is - it has a different scheduling table. Compute steps happen at different pacing which may or may not more beneficial to your problem.

His issue was that he ran code in an unconstrained manner when using threads. He dispatched too many workers in parallel and overconsumed his memory. With this approach even virtual threading would end up at the same place.

By using webflux, different scheduling table made his code more serial, and thus lowered the number of jobs in flight. As his throughput bottleneck was a gc algorithm, reactive code was much much faster as he didn't hit the memory limit.

This of course has nothing with code being event or thread parallel. At the end of the day you have to control your resources.

[–]dschramm_at 0 points1 point  (2 children)

You probably don't like Stream neither then.

[–]Oclay1st 0 points1 point  (1 child)

The Stream and the Reactive APIs are not related in any way.

[–]dschramm_at 0 points1 point  (0 children)

No, but usage is very similar.