Skip to content
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

Zuul Connection Pool properties #1819

Open
mehmetgul opened this issue Sep 11, 2024 · 2 comments
Open

Zuul Connection Pool properties #1819

mehmetgul opened this issue Sep 11, 2024 · 2 comments
Labels

Comments

@mehmetgul
Copy link

Hi Team,
I was testing and trying to understand the behaviour of zuul properties but I need more info specifically on perServerWaterline.
I check the documentations and googled a lot but didn't get enough info.
Ribbon Client Config Property <originName>.ribbon.MaxConnectionsPerHost <origin>.concurrency.max.requests <originName>.netty.client.perServerWaterline //default value=4

I got clarifications on MaxConnectionsPerHost and max.requests but when I tested the perServerWaterline didn't understand its behaviour.
I was testing the connection limits and I set the perServerWaterline=1 and run performance test for 20K req/min and 40K req/min with 1 sec, 2sec and 4sec delay. Total 5 test. (Attaching the brief test result)
I know that this property is for per server, per event loop and per event is for 1 CPU.
So we are having 2 container and each container having 2CPU.
Base on my test results the error rates are very less despite of setting the limit 1.
Do we suppose to set another property along with this or this property is meant to handle in different way?
I having difficulty to understand the purpose of this property.
Can someone provide more details on this property.
Thanks
[
Screenshot 2024-09-11 at 11 09 32 AM
]

@jguerra
Copy link
Collaborator

jguerra commented Sep 16, 2024

perServerWaterline controls how many idle connections a single event loop can have to a particular server in its connection pool. Setting perServerWaterline=1 essentially disables connection pooling since the connection will be closed when it is returned to the pool, see PerServerConnectionPool.release().

Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the Stale label Nov 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants