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

Re: OpenLdap Capacity

For my experience, these factors will be most important:

1. ACL syntax and structure. Poorly written (or even well written but complex) 
ACLs will make the biggest impact on performance. Try setting debug level to 64 
(I think; whatever ACL check is) for a query or two. I have had single queries 
generate over 50 pages of logging info! The ACL algorithm is very granular, and 
can require LOTS of cycles to resolve.

2. Proper indexing. Good indexing will dramatically improve performance. An 
occasional slapindex is a good thing too. Know where to use eq, pres, and sub.

3. Code efficiency. Good queries are fast and efficient. Make sure you do not 
do any iterative queries (if possible), especially ones that are on non-indexed 
attributes and require lots of ACL checks.

4. Socket resources. If you can pool filehandles and avoid creation/tear down 
for most requests, you will be able to support more users.

5. Client buffering and caching settings. Well designed client caching and 
bufferng will make life MUCH easier on you. You must be very careful in your 
code, but this can increase performance dramatically.

If you can do all those things, you will be able to scale quite easily to 
hundreds if thousands of objects with several thousand concurrent connections 
and dozens of requests per second. Do them poorly and a single user with a 
single query will seem dog slow.

Kevin

Quoting "Evaristo-Jose Camarero (ECE)" <Evaristo-Jose.Camarero@ece.ericsson.se>:

> 
> Hi all:
> 
> I'd like to know any estimation about LDAP capacity over Linux (for instance
> with a PC with 800 Mhz and 512 MB). What is the max number of users with
> heavy traffic? At least some rough estimations.
> 
> Chiao,
> 
> 	Evaristo José Camarero del Río
> 	Systems Engineer
> 	UMTS/GSM Systems Management
> 
> > Ericsson España, S.A.		Phone:	+34 91 339 4200
> > Ombú, 3	 			Fax: 		+34 91 339 2538
> > 28045 Madrid, Spain		E-mail: 	evaristo-
jose.camarero@ece.ericsson.se
> > 
> > 
> 




-------------------------------------------------
This mail sent from Biltmore Communications
	http://www.biltmorecomm.com