Sound like you need to do some work on your DB_CONFIG and LDAP indexes. Do you know where your bottleneck is? Disk I/O, Processor, Memory context switching, etc?
Are you using nss_ldap? Unless they have changed it recently, nss_ldap does group lookups very inefficiently. (Instead of searching for groups the user is a member of it searches for all groups and then looks for the member ID.) If you can, you may want to disable ldap lookups for group membership and/or use nscd. On Wed, Nov 10, 2010 at 7:45 AM, John Jasen <[email protected]> wrote: > While I realize this is a way to start a very open-ended conversation, > I'm curious what sort of performance we should expect out of an openldap > server, when the queries run against it are mostly NIS schema stuff -- > uid/username lookup, group membership and gid lookup, etc. > > From some brief tests, it seems that our test openldap server tops out > at about 2400 queries a second, where the clients (ranging from 50-900 > clients) ran a mixed bag of id and getent. > > The system is a quad core dell 1950, 2gb RAM, running Debian Lenny > x86-32, and openldap 2.4 from the Lenny repositories. > > So, the two part question is: a) is this reasonable performance? and b) > where should we look to optimize? > > -- > -- John E. Jasen ([email protected]) > -- "Deserve Victory." -- Terry Goodkind, Naked Empire > _______________________________________________ > Tech mailing list > [email protected] > https://lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > -- Perfection is just a word I use occasionally with mustard. --Atom Powers-- _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
