-
Notifications
You must be signed in to change notification settings - Fork 74
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
Dropping the number of clients in the ingress benchmark #452
Conversation
70589e8
to
e8d0212
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
53cde40
to
9004fa1
Compare
9004fa1
to
f6a4ba4
Compare
Is there a reason you're changing the small scale routes/clients? |
From my test result for large scale 500 mix, 10 clients is ok too. https://docs.google.com/spreadsheets/d/1jNYCdTu2XvSs4xARk8PwQGoPZVgra0jOQORIlUKAdKg/edit#gid=1789221797 For default 2 routers, Capacity: For mix 500 routes 10 Clients, Real: Real 30k < Capacity 40k --> OK |
…narios Fixes: cloud-bulldozer#451 Signed-off-by: Raul Sevilla <[email protected]>
f6a4ba4
to
010bd6b
Compare
I wanted to ensure that we not run out of ports in any of the router pods because of irregular request balancing. Anyway, I've tested with the number of clients you suggested with good results (just some negligible 0 status codes) and I've pushed the changes. |
The number of clients was also excessive in this scenario. If you still need something specific for your tests, I recommend you to overwrite the required variables. |
@rsevilla87 It looks good. Shall we merge this? |
Fixes: #451
Signed-off-by: Raul Sevilla [email protected]
Description
We shouldn't use maxConnection=-1, as we always work with OOTB parameters, as the goal of the benchmarks is not reaching the best results, but to detect performance regressions. The parameter maxConnection=-1 is already part of the ingress-controller tuning guide.
Reducing the number of clients to prevent running out of connections, this should help to increase test stability, this parameters is configured OOTB with
maxconn=20000
Also, reducing the test scope, by removing one of the clients iterations. cc: @qiliRedHat
With this change:
Large-scale:
20 clients: 20 x 500 routes x 2 (edge and re-encrypt terminations) => up to 20K connections
mix termination @ 10 clients: 10 x 2000 routes x 1.5 (edge and re-encrypt terminations) => up to 30K connections
Preliminary results after a couple of runs in different 4.11 clusters based on OpenShiftSDN are pretty stable (max observed deviation was 9.53% )
Small-scale:
100 clients: 100x100 routes x 2 (edge and re-encrypt terminations) => up to 20K connections
mix termination @ 50 clients: 25 x 400 routes x 1.5 (edge and re-encrypt terminations) => up to 30K connections