This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: timeout in LDAP access

On Jun 19 19:53, Denis Excoffier wrote:
> On 2014-06-18 20:01, Corinna Vinschen wrote:
> > On Jun 18 10:33, Corinna Vinschen wrote:
> >> 
> >> 
> >> The idea I was proposing was just to drop all attempts to seconds guess
> >> how fast a DC replies.  We're going to use LDAP with default settings
> >> and that's it.  Default settings means, every operation times out after
> >> the default timeout period of 120 seconds, which should really be
> >> sufficient.
> > 
> > I'm not quite sure I understand the effect of all the timeout values in
> > LDAP entirely correctly and the API documentation leaves quite a bit to
> > be desired.
> > 
> > For the time being I raised the timeout to 30 seconds, and colons in
> > the gecos field are converted to semicolons.  I uploaded a new developer
> > snapshot to  Please give it a try.
> I tried the last snapshot. First the ${tr â:â â;â} operation works perfectly,
> and the last field (of 'getent passwd' is now always the homedir. You may
> like to correct a typo in the ChangeLog, should be âsemicolonâ instead of
> âcommaâ.
> Also, i tried with several different values for CYG_LDAP_TIMEOUT. With 45s, 60s,
> 115s and 125s, i obtained no timeout (outputing 500000 users takes 1h).
> I tried 3 times with 30s and got once with no timeout, once with one timeout
> and once with 3 timeouts (ie one timeout for 3 domains).
> In any case, if you wish to switch to timeout=120s is ok for me.

Here's another question, which occured to me over the weekend:

Do you really *want* to enumerate 500K users when accessing the DCs
remote over a slow DSL line?  Isn't this a situation in which you'd
rather like to avoid enumerating accounts or restrict it to an
essential subset?  That's what db_enum would be good for.

What I'm really concerned about is not the enumeration functionality
getpwent/getgrent, but the "normal" functions accessing a single
account.  Accessing a single account, even over a slow line, shouldn't
be that slow.  And even if it is, it's only the supplementary
information (gecos, home, shell, *iff* any of them is set in AD at all)
which might be wrong.  Do we really want to introduce a long timeout
for this?  I don't think so.

I'm rather inclined to revert the timeout for single account access to a
smaller value again (5 or 10 secs) and introduce a second, longer
timeout value for enumeration (60 secs, for instance).

I've applied a patch to to this effect.  Would you mind to give
it a try?

> The PageSize
> (100) could also be changed?

Yes, the pagesize can be changed, too.  I'm just not sure about the
consequences.  In my pretty small AD environment 100 seemed to be a
good compromise in terms of performance and size (as I mentioned, just
4 KB per page).  Less than 100 slowed down getent noticably, more than
100 didn't provide a visible speedup.

Can you test in your big environment in how far raising this value
changes the performance and the chance for timeout?  Since the load is
on the server, it should be pretty fast in collecting the next X SIDs.
I'm just a bit concerned about the (unnecessary?) network traffic this
might generate.

> Here two remarks about timeouts:
> 1) for most of the 100-sid chunks, the high timeout is not used, therefore
> the global penalty in delay is not so high. And perhaps a 120s timeout is high
> enough so that when it is met, we could abandon not only the current domain,
> but also the whole search?

Would that be really a bright idea?  Assuming your ADs (and their DCs)
are in different remote locations,  One of those connections being down
would disable enumerating other domains.

> 2) if value of timeout is not high enough (i have no figuresâ), timeout may
> occur when the PC is in fact occupied with other tasks (eg antivirus scanning
> or something else), unrelated to network delays or server latencies.

No timeout is prepared for a CPU being 100% in use :|


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpDwcri_ybnz.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]