directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Plea for help with search performance
Date Wed, 11 Apr 2012 15:18:40 GMT
Here's an LDIF example of my entries. UID's are used in the dn, not CN. 
The login process searches for an entry like this. 


If the SearchResult yields 1 entry, then we get the entry DN and bind with the DN  and the
supplied Password.

In other parts of the application, option selects are filled with uid=value, displayName =
This is why we also need to search for displayName.

Both attributes are indexed with cache size of 50000 but results take 20 seconds to return.

dn: uid=1334083815683,ou=users,ou=int,o=cpro
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: 1334083815683
title: Snr Operations Technician (D)
sn: Awg-Rosli
departmentNumber: SMDS - UIA/G/MMO52D
cn: Awg-Rosli, Awg-Abd-Rahim SMDS-UIA/G/MMO52D
description: UI - S
telephoneNumber: 555-1212
givenName: Awg-Abd-Rahim
businessCategory: Ops MDS (Malaysia) Sdn Bhd
displayName: Awg-Rosli, Awg-Abd-Rahim SMDS-UIA/G/MMO52D
employeeNumber: A-A-R.Awg-Rosli
pwdPolicySubEntry: ads-pwdId=cproint,ou=passwordPolicies,ads-interceptorId=authenticationInterceptor,ou=interceptors,ads-directoryServiceId=default,ou=config

Carlo Accorsi

-----Original Message-----
From: Emmanuel Lécharny [] 
Sent: Wednesday, April 11, 2012 10:47 AM
Subject: Re: Plea for help with search performance

Le 4/11/12 4:31 PM, a écrit :
> Hi, we have a project has 80,000 users in one OU. This is a requirement.
Hmm, you mean 80 000 entries under ou=something, I guess ?

Like :

cn=user1, ou=something
cn=user2, ou=something
cn=user80000, ou=something


> With guidance from this group, I've tried dozens of combinations of 
> indexing attributes, setting their cache sizes, increasing the partition caches, timeout
settings, etc.
> We're using the 64 bit java  service wrapper and have given the JVM 5GB of memory.
> Despite this, we still have 20+ second response times when searching on displayName and
employeeNumber .
> This is consistent with multiple ldap clients.
That's not normal. It should be immediate.

Can you tell us what kind of request you send to the server ?

Also what kind of network configuration are you going through (firewall, etc). It would be
interesting to see if you get the same 'level' of (un)performance if you do the search on
the server.
> Every time we've made configuration or index changes, it's been to a clean empty system
and then we load our LDIF file with the 80k users.
> You've all been very helpful to us but we're backed into wall with this.
> The response times are unacceptable and we don't know what else we can do.
Yeah, I understand. It's definitively not acceptable, and we never had such performances on
our tests, even with 5 000 000 entries under one single branch.
> Could someone provide us with an idea of how to configure the system 
> to get the best performance when searching for displayName and employeeNumber? The displayName
lengths are up to 80 characters, the employeeNumber is 25.
The best thing is certainly to index those two attributes. You might also face a bug. Which
version of the server are you using ?

Thanks !

Emmanuel Lécharny

View raw message