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: Testers needed: New passwd/group handling in Cygwin


On Feb 26 11:02, Corinna Vinschen wrote:
> On Feb 26 08:09, Achim Gratz wrote:
> > > Sorry, I don't grok this.  What has a web application server to do with
> > > asking a DC for user info?
> > 
> > We have one of these that does a lot of DC lookups because it authenticates
> > all users.  It's also in a much faster network, so I can check there what
> > the lookup rate could be reasonably expected to be.
> > 
> > > Erm... how often are you calling id, usually?
> > 
> > I'm currently doing this in the login process to figure out whether the
> > prompt should show "root" powers.  I'll have to figure out something else to
> > do instead.
> 
> No, you don't.  I'm actually doing the same.  Let's keep up with this
> and try to make Cygwin faster in the first place.

I just created 400 groups in AD, and added myself as member.  An `id' on
a 32 bit Windows 7 domain member machine in my tiny network consisting
only of a handful of Windows VMs and with me as the only real user takes
about 3.6 secs with the latest code from CVS, using a non-optimzed
Cygwin DLL.

> > > Also, we're in the early
> > > stages of testing this change.  The idea is not that you just switch,
> > > the idea is that we *test* this and I get enough feedback to be able to
> > > ease the biggest pains.
> > 
> > Understood.  Until now I had to generate passwd and group files and I was
> > hoping that the need for doing that would go away (I'd also need to talk to
> > our AD folks so they start populating the correct fields).
> 
> Yup.  Feedback from AD admins is greatly appreciated.
> 
> > > Other than that, I just had an in-shower inspiration how to speed up
> > > `id' specificially.  The getgroups(2) call is in the center of this and
> > > I could probably speed up the stuiff a lot by opening the LDAP
> > > connection in getgroups only once. 
> > 
> > Thursday?  :-)
> 
> Hmm, probably.

With this patch applied, the aforementioned `id' now takes about 1.9
secs, in an otherwise identical scenario.

> > > Also, more radically, if we drop the functionality to define another
> > > group name for a group, we could drop the requirement to open an LDAP
> > > connection to fetch group information to the DC entirely(*).  This would
> > > only affect domain groups, local groups could still have different
> > > names.  But I'm already wondering for a couple of days if having a
> > > Cygwin group name different from the Windows group name is really
> > > necessary at all.  I added this years ago for fun, but there's no
> > > serious reason I can think of which would require to keep up with this.
> > > 
> > > (*) Assuming the group info is cached in the local LSA, which is
> > >     pretty likely for the groups of the current user.
> > 
> > That would also work for me (I don't think I've ever used that feature
> > consciously).

With this patch applied as well, `id' now takes constantly 0.4 secs.

Note that this speedup is only possible when fetching lots of group
account information.  For user accounts we still need the info from AD,
but apart from the getpwent functionality, which can be restricted via
the db_enum setting in /etc/nsswitch.conf, there's not very often a good
reason to fetch information for hundreds of user accounts.

Anyway, if I send you the link to two DLLs with these patches, would you
mind to test their speed in your environment?


Thanks,
Corinna

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

Attachment: pgpKfqvKYSPM_.pgp
Description: PGP signature


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