Improving performance of winbindd_list_groups

[Steven Danneman]

My current pain point involves winbindd_group.c:winbindd_list_groups()
but I believe everything described here also applies to
winbindd_user.c:winbindd_list_users().

We have a somewhat complicated domain topology setup including a primary
domain with 2000 groups, a trusted domain with 10,000 groups, a trusted
NT4 domain, and a trusted domain with a slow link.  When attempting a
"wbinfo -g" command on a machine joined to our primary domain, the
command is waiting ~60 seconds and then erroring out.  Upon
investigation, there's no error, winbindd's response is just exceeding
the max timeout that wbinfo will wait.  This is due to the groups from
all trusted domains being sequentially enumerated by the main winbindd
process in winbindd_list_groups().  Combined across all domains this
sequential enumeration takes ~85 seconds with the longest domain taking
32 of those seconds.

This function seems ripe for optimization.  With all the existing
winbindd asynchronous framework available, we shouldn't be sequentially
enumerating groups from each domain, but instead querying them all
simultaneously.  Thus, setting an upper time bound for the operation to
be the slowest domain, not the combined time of all domains. 

My proposal is to rewrite winbindd_list_groups() (and subsequently
winbindd_list_users()) to asynchronously enumerate groups from all known
domains simultaneously using async_domain_request() and calling
get_sam_group_entries() from the winbindd_child_dispatch_table.

As I get coding can anybody point out any obvious flaws in this plan?
Is there a reason this group enumeration must be done from the parent
winbindd process or must be serial and not parallel?

Steven Danneman | Software Development Engineer
Isilon Systems    P +1-206-315-7500    F  +1-206-315-7501
www.isilon.com        
How breakthroughs begin. (tm)