> If I was to put the registry into ldb, then I would expect
> EnumValue calls to be frequent. I don't have hard numbers,
> but one reason to put smb share definitions into the
> registry was to make the 10.000-share server possible. Make
> that 3 custom smb.conf settings per share, and you end up
> pretty quickly with a number of registry values that
> preclude a full tdb dump on every tconX.
Why do you need an EnumValue call on tconx?
> Sorry, but I have to disagree here. I had to optimize
> winbind with about 30.000 entries in winbindd_idmap.tdb. It
> spent a good share of CPU walking the degenerated tdb hash
yes, but that is because winbindd is serving application that make
thousands of these calls without any user interaction. So winbindd
must answer queries in the order of milliseconds or better.
What I don't know of is an application that does anything like the
same for onelevel ldap scope based searches.
> This was partly due to the users being in quite many
> groups, and winbind had to do sid2gid calls on all groups.
> This on a server where 17.000 users did session setups
> within 60 minutes. Not fake, this is a real world server.
sure, and I've spent time optimising this sort of case too. Notice I
recently wrote a benchmark in smbtorture that tests this sort of case
with ldb, and I found it was too slow compared to tdb, so I started an
effort to fix it. This sort of case really matters.
> It's not the huge databases, it's that *many* calls to the
> non-indexed search might be necessary.
ok, so can you give me an example of where this onelevel search will
happen with other than a GUI application doing a tree walk?
> I just doubt scanning a big tdb on every tconX is a good
> idea, but that's just me. Traversing a tdb has just hurt us
> too many times.
maybe the problem is that I don't understand the reference to tconx
here. How does tconx cause a onelevel ldb search?