DialTLS occasionally either timeouts or fails with "connection reset by peer"

[EvgenyAGRO]

Once in a while the API call will fail with one of the following (hosts and ips redacted):
LDAP Result Code 200 "Network Error": dial tcp: lookup: read udp: i/o timeout
LDAP Result Code 200 "Network Error": read tcp: read: connection reset by peer

This happens occasionally, with most of the calls go through (99% of the time) and all of a sudden failing once.
Using go-ldap v3.0.2

For each incoming request a new connection is created using ldap.DialTLS, bind is called conn.Bind after the request has finished the connection is closed in defer.

Additional info:

• LDAP AD user exists, DNS lookup to host works
• No Loadbalancer/Firewall present
• DefaultTimeout of 60 seconds is used (as specified by default)

Trying to figure out what could be the reason for these sporadic failures. Maybe too many connections? Should I cache created connections, is the mentioned usage pattern ok?

[cpuschma]

Do you properly close the connections after using it? The target host/server might refuse to open any additional connections if the others are still dangling. For me, I didn't experience this and in my use case, I've multiple firewalls in between and ~120 binds / second.

Maybe too many connections? Should I cache created connections, is the mentioned usage pattern ok?

I would recommend re-using already established connections. For me, it brought a massive perfomance gain. When you implement it, just make sure to occasionaly (or when trying to do any operation) check for faulty connections. They can be killed abruptly without any notification to the client / server and you might run in an error if a connection has been pooled for too long and the server dropped the it in the meantime.