On Thu, Oct 06, 2011 at 07:16:45PM -0700, Craig White wrote:
> On Thu, 2011-10-06 at 19:10 -0400, Stephen Harris wrote:
> > LDAP is slow. nscd, sssd, ldapcachemgr et al are all klduges to work
> > around that fact.
> OpenLDAP is highly optimized and very fast and can search a large DSA
> much quicker than you can search a large passwd/group setup. Maybe the
*sigh*
I recently stress tested one of our LDAP servers; it handled 100,000
simultaneous collections and performed over 24,000 group "memberid"
searches per second.
The servers are fast.
The protocol is heavy and slow. You can only get that sort of performance
with persistent connections; ie client side kludges.
> For the record... ldap does have a 'socket' mode that one can use on a
> local machine where speed is of the essence so that sort of blunts the
> point you are trying to make about TCP/IP speeds.
If you want to install software on 30,000 machines... yet another kludge.
> I would agree with NSCD adding additional mode failures. I try not to
> use it. I know nothing at all about other cache technologies for LDAP.
It's _essential_ for reasonable LDAP performance. Back in the good ol'
days of NIS, "nscd" got the nickname of "Needless Sun Complexity Daemon"
because it was optional and caused more problems than it was worth.
Everyone disabled it. With LDAP if you don't have nscd then your
performance drops massively and you put a much larger load onto your
LDAP servers.
> SSD really isn't about user/group caching and I'm not sure how that
SSSD is the RedHat 6 replace for nscd; it replaces nscd for LDAP
communication and caching.
> Personally, I think you are making a fallacious argument and offering no
> empirical evidence, no comparison testing methodology and no evidence of
> anything worthwhile to consider.
... and we drop into ad hominem attacks.
FWIW, anyone can do these tests. Write a loop that does 10,000 ypmatch's
and a loop that does 10,000 ldapsearches. Time 'em. Oh. (Run "netstat
-an" and watch the tcp sockets! Oh!!). This demonstrates the utter
essential nature of nscd. Now with nscd with services configured for
LDAP in nsswitch and run 20 'netstat -a' commands (without the 'n'
option, to force getservbyport() queries). Whee. (Maybe this has been
fixed, now; we bitched enough at Sun and RedHat). Create a /home with
10,000 users and do an "ls -l". Awww...
Do the same tests against NIS and watch speeds come up. It's possible
for NIS to be _faster_ (even without nscd) than even a local passwd
and group file 'cos the NIS maps have a primary index and are built
in multiple ways (passwd.byname, passwd.byuid for example). LDAP has
indexes (multiple indexes!), but the protocol slows you down.
Note: I'm not saying "don't use LDAP". LDAP is so much more superior than
NIS in almost every respect, except speed. Work hard on those kludges
(nscd,sssd,ldapcachemgr etc) to bring performance back to a reasonable level.
Use LDAP profiles to automatically configure clients to the closest servers,
and so on. You'll get a usable LDAP infrastructure. Just it's now more
complicated than NIS and has more failure modes as a result.
LDAP is definitely a case of 2 steps forward, 1 step back.
--
rgds
Stephen
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
