Hi William,
These errors are only shown on the client, yes? Is there any evidence
of a failed connection in the access log?
Correct, those 2 different contacting ldap error issues. I have searched
for various things in the logs, but I havent read it line by line. I
dont see "err=1", no fd errors, or "Not listening for new connections -
too many fds open".
We encountered a similar issue recently with another load test, where
the load tester wasn't averaging it's connections, it would launch
10,000 connections at once and hope they all worked. With your load
test, is it actually spreading it's connections out, or is it bursting?
It's a ramp up of 500 users logging in and starting their searches, the
initial ramp up is 60 seconds, but the searches and login/logouts is
over 6 minutes. I just spliced up the logs to see what that first
minute was like:
Peak Concurrent Connections: 689
Total Operations: 18770
Total Results: 18769
Overall Performance: 100.0%
Total Connections: 2603 (21.66/sec) (1299.40/min)
- LDAP Connections: 2603 (21.66/sec) (1299.40/min)
- LDAPI Connections: 0 (0.00/sec) (0.00/min)
- LDAPS Connections: 0 (0.00/sec) (0.00/min)
- StartTLS Extended Ops: 2571 (21.39/sec) (1283.42/min)
Searches: 13596 (113.12/sec) (6787.01/min)
Modifications: 0 (0.00/sec) (0.00/min)
Adds: 0 (0.00/sec) (0.00/min)
Deletes: 0 (0.00/sec) (0.00/min)
Mod RDNs: 0 (0.00/sec) (0.00/min)
Compares: 0 (0.00/sec) (0.00/min)
Binds: 2603 (21.66/sec) (1299.40/min)
With these settings below, the test results are in, they still get 1
ldap error per test.
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
Suggestions ? Should I bump these up more ?
Thanks,
Gary
On 10/14/24 20:42, William Brown wrote:
Ah yes of course. Here is 1 run of their web app load test, it is 6
minutes long, and it should mostly be only the test it self. I will
start looking for
We encountered 2 "Can not contact ldap server" errors during this run.
2 cant contact ldap server errors in this run below.
These errors are only shown on the client, yes? Is there any evidence
of a failed connection in the access log?
After the run I bumped up these from 4096,
net.ipv4.tcp_max_syn_backlog = 6144
net.core.somaxconn = 6144
Yet we still get the ldap errors (this one and the start tls request
error previously mentioned.)
Should I bump up the nsslapd-listen-backlog-size,
net.ipv4.tcp_max_syn_backlog, net.core.somaxconn more ?
We encountered a similar issue recently with another load test, where
the load tester wasn't averaging it's connections, it would launch
10,000 connections at once and hope they all worked. With your load
test, is it actually spreading it's connections out, or is it bursting?
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
