search

mzubal / spring-reactor-benchmark

Basic performance benchmark of Netty/Reactor based REST API vs Tomcat/blocking Spring
MIT License
12 stars 3 forks source link

Thread.sleep() allows for context switching #1

Open jimador opened 5 years ago

jimador commented 5 years ago

I think this test would be better served if you took out the sleep/delay and added something that "does work". I forked your repo here and made a simple update that replaces the sleep/delay with a bubble sort. The Gatling tests are drastically different. The all requests to the reactive app die after the pool is saturated. I'd assume that this is expected behavior. As soon as a "reactive" application starts to experience heavy load, some sort of autoscaling should kick in to compensate. Anyway, just food for thought, I thought it was interesting.

mzubal commented 5 years ago

Hi James, thanks for your suggestions - I appreciate you took some time to play with this project! I get your point with context switching and doing some actual work. The point of the project (as mentioned in the README) was mainly to do comparison between non-blocking netty vs blocking tomcat threads in the context of I/O intensive applications (which is the case for most of the "business" apps as they call other APIs or wait for DB queries most of the time). I think Thread.sleep() is a good way to simulate I/O for this purpose. I totally agree this demonstrates just one part of the problem the reactive apps solve. It would be also great to do a benchmark to demonstrate that reactive approach would do much less context switches for the same scenario. Did your benchmark with bubble sort show different results for netty vs tomcat? I'll try to check your fork and experiment with that later (if I get some time :) ). Feel free to submit any PR and I'll be happy to check/merge it! Thanks again for contributing this way!

jimador commented 5 years ago

Hi Miloš,

I agree that as long as the IO is "off-box" the Thread.sleep() is a good way to simulate waiting. I've updated my fork with the results from the Gatling tests. What I'm seeing is that the Tomcat app performs "better" than the reactive app when you have some compute intensive blocking operation during the request. The Reactor app applies an "equal misery to all" as the thread-pool is exhausted (which, makes sense, and is what I'd expect it to do). I'll do a PR (possibly just pull it into another branch) here in a bit so you can check it out. Thanks again for humoring my curiosity. :)