[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Help: Slow LDAP search with high %iowait



Hi,

Victor <victorfuman@yahoo.com> writes:

> Hi Dieter,                                                                                                            
>                                                                                                                       
> Many thanks for your response. I increased the cache size by 10 times in both                                         
> slapd.conf and DB_CONFIG. The performance got improved, but not impressive.                                           
> For example,                                                                                                          
>                                                                                                                       
> Searching by first name only using "scott*" only (for wildcard) for the 1st                                           
> time still took 12937 ms to find 881 users (BTW, I was using SpringLDAP  Java                                         
> client). My other responses are inline.

Ah, java clients. Performance of java clients is really a design
matter. To my experience in most cases java clients are badly designed
and in most cases responsible for performance loss.
Try OpenLDAP tools or a benchmarking tool to get comparable results.
Something like 
time ldapsearch <parameters>,
charge, http://loadtesting.sourceforge.net,
slamd, http://www.slamd.com.

>
> I wanted to consider scaling factor. If we use OpenLDAP in production, we will                                    
> have over 350million user entries. I probably don't want to put so many                                     
> entries in cache unless it is really needed. That is why I used a relatively                                    
> small cache in my prorotyping (in the hope it can scale up).

Howard Chu has conducted some large scale tests, search the archive
for his reports.
  
> Did I have a flaw in organizing/grouping the data/entries? Any further advice                           
> will be greatly appreciated. Thanks.

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E