Re: timeout and network-timeout values of zero for syncrepl in LAN replication
On 4/18/2024 11:30 AM, Howard Chu wrote: An LDAP operation may have more than one response. Search operations often do, extended ops may as well. The timeout is waiting for any response, not just the operation result. Ah, that makes sense now. Thanks, Howard! -- Chris Paul | Rex Consulting |https://www.rexconsulting.net
Re: timeout and network-timeout values of zero for syncrepl in LAN replication
Christopher Paul wrote: > On 4/17/2024 11:24 PM, Howard Chu wrote: >> timeout has nothing to do with the duration of an operation. > > I'm confused then. Manual page ldap.conf(5) states: > > TIMEOUT > Specifies a timeout (in seconds) after which calls to > synchronous LDAP APIs will abort if no response is received. Also used for > any > ldap_result(3) calls where a NULL timeout parameter is supplied. > > The duration of an operation is the call to the LDAP API plus the time it > takes for the response/result, no? What am I missing here? The manpage language is precise. Your paraphrase is not. An LDAP operation may have more than one response. Search operations often do, extended ops may as well. The timeout is waiting for any response, not just the operation result. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: timeout and network-timeout values of zero for syncrepl in LAN replication
On 4/17/2024 11:24 PM, Howard Chu wrote: timeout has nothing to do with the duration of an operation. I'm confused then. Manual page ldap.conf(5) states: TIMEOUT Specifies a timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. Also used for any ldap_result(3) calls where a NULL timeout parameter is supplied. The duration of an operation is the call to the LDAP API plus the time it takes for the response/result, no? What am I missing here? -- Chris Paul | Rex Consulting |https://www.rexconsulting.net
Re: timeout and network-timeout values of zero for syncrepl in LAN replication
Christopher Paul wrote: > Concerning the "timeout" parameter, the ideal range might be between 60 to > 120 seconds, to handle operations exceeding a minute, but again, kicking in > retry > logic if they exceed two minutes. I admit that my stance on the "timeout" > setting is tentative, given that search operation duration hinges more on the > provider's responsiveness rather than network speed alone. timeout has nothing to do with the duration of an operation. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: timeout and network-timeout values of zero for syncrepl in LAN replication
--On Monday, April 8, 2024 3:08 PM +0900 Christopher Paul wrote: Hello OpenLDAP-technical list, I'm curious about community perspectives on a specific LDAP replication timeout and network-timeout settings: Setting "timeout=0" or "network-timeout=0" within a syncrepl/olcSyncrepl definition for replication settings is not the best practice for LAN environments. These parameters, when set to zero, instruct syncrepl to wait indefinitely for connections and replication operations to conclude. Within a LAN context, establishing new connections should ideally occur in less than a second. Delays beyond a couple of seconds should kick in the retry logic. This suggests that a more fitting network-timeout range is between 1 to 5 seconds. Concerning the "timeout" parameter, the ideal range might be between 60 to 120 seconds, to handle operations exceeding a minute, but again, kicking in retry logic if they exceed two minutes. I admit that my stance on the "timeout" setting is tentative, given that search operation duration hinges more on the provider's responsiveness rather than network speed alone. This approach ensures that LDAP replication remains both responsive and resilient, without compromising on efficiency or performance. Thoughts? It's generally never been an issue in the networks I've been on. Also with refreshAndPersist these settings are only for the initial connection. If I was doing refreshOnly I'd definitely want to tweak them. I'd make sure and set the tcp keepalive settings as well for sync replication, because the biggest grief I've had since moving to syncrepl around 2006 is with firewalls and other network devices. There was someone I corresponded with many years ago who was doing syncrepl in an unstable network environment (their nodes were distributed across Mexico IIRC, and the links were not stable), and managed to get it solid when tweaking the parameters you mention. If they're still active, it'd be interesting to hear their feedback. --Quanah
