-
Notifications
You must be signed in to change notification settings - Fork 654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Latency Increase as Connections Increase #654
Comments
These results are aligned with other reports and are considered issues at least on our part. We also have slightly different default setup on the tcp and thread side that could affect it. Thanks for the repos that will help us identitify the gap and see with its related to the same causes of the existing issues. |
@dave-fl is this |
@dave-fl Is it possible it is something in the setup? I have 2 VMs, on the first I have Reactor Netty
Vert.x
|
@dave-fl, a couple of comments to start. The description of wrk2 explains deficiencies with using wrk for measuring latency especially in the high percentile. To my knowledge Gatling has those addressed. Also for WebFlux a more fair comparison would be to functional endpoints, vs the annotated programming model which does more and is expected to have some overhead. Not saying this as conclusion, just something to consider. It would be good to see numbers with wrk2 or Gatling and WebFlux.fn. |
Ok so I setup two So why is this happening? It seems that many who are testing this could be bound by CPU. Top was showing CPU to be around 340 for Vert.X and 540 for Reactor. Webflux was 795. I tried both default and epoll. Did not see a difference. Webflux is still the laggard.
|
Alright last run. Using wrk2. Also optimized the Webflux Functions to use buffers and ran on a bigger machine (16 cores, so I wouldn't top out the CPU, I can saturate the NIC now even with Webflux). You see more CPU usage with Reactor + Larger Deviation.
|
@dave-fl Thanks, Stephen |
@dave-fl if you can try this branch https://github.com/reactor/reactor-netty/tree/MonoSend-experiment locally, we are polishing it but it showed great promise on my machine ? |
@smaldini @violetagg Just tested this branch. Huge improvement. Performance is way up, stddev is very small. CPU usage is way down. About 270-300 during the run (previously was about 480). When is this going into the main branch :)
|
Hi, |
@benitocm No. I think the key is that CPU and standard deviation is down. When a new build is made, I can do some more tests for gateway too. At that many connections, some of the native transport settings such as SO_REUSEPORT will likely become important. |
|
You can use my example repository. Just make sure to build with the referenced branch. Also. Don’t run this on the same machine. Take note of what I tested with. These were well performing machines on AWS - C5.4xlarge and C5.2xlarge. I can’t comment on Webflux really, I didn’t retest it. The performance with Webflux Functions previously was ok, but did have higher CPU. Webflux without functions was bad. It was unable to saturate the link, maybe now it can. If you have specific questions send them on gitter. But I suggest you establish a baseline and see how your other setups compare. |
Good news @dave-fl |
Core changes have been merged (#725) and scheduled for 0.8.7.RELEASE/0.9.0.M1 tomorrow. |
I am seeing that latency at the 75%, 90% and 99% is increasing compared to some other Netty based frameworks - total throughput here about 30% less. This seems to be directly related to an increase in load. As connections increase - the average latency doubles relative to Vert.x.
My setup is not perfect - better hardware would reveal more. But I believe it is enough to demonstrate.
Container 1 is a Docker container that has wrk.
Container 2 is one of Vert.X, Reactory Netty or Webflux
All running on PCF - no HTTPS.
Each app accepts a parameter that specifies how many characters to return. Once this value is computed it is cached in a concurrent map so subsequent retrieval times are constant. I am using a 10kb string for GETs only.
Below are the results. The repot with these back ends can be found here
Also, I don't known why but the results for Webflux aren't even in the same league. About 20%-30% the throughput. Maybe @rstoyanchev can comment here.
Do you consider these results to be as expected or is there room for tuning here?
The text was updated successfully, but these errors were encountered: