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

Re: performance & benchmarking



At 10:11 AM 10/4/99 -0700, casey@seattle.gii.net wrote:
>Developers,

This list is for discussions related to the development of
OpenLDAP software.  Questions concerning the use of OpenLDAP
software belong on the software list (see list charters at
http://www.openldap.org/lists/).   Questions specific to some
other vendors belong on vendor-specific mailing lists.  General
topics (not specific to any vendor) can be posted to our
general list.

Please redirect your enquiry (and follow ups) to the most
appropriate forum.  Do not cross post.

>We've been using the umich ldapserver and later openldap for a number
>of small projects, and have never really had a lot of problems with 
>performance, but lately the requirements have gone up quite a bit, and we're 
>now looking at implementing solutions for upwards of 10,000,000 entries 
>in a directory, 10 - 20 read operations/sec and upto 10 write operations/sec.

See the software list archives and FAQ on how to tune OpenLDAP to
achieve such goals.

>We've looked at innosoft's idds and icl's i500 servers, which atleast claim 
>to be able to handle large amounts of entries, and promise fairly painless 
>scalling to distributed systems... but what I havent seen are actual 
>benchmarks with real-life applications. Can anyone help ? 

I suspect they (or any major LDAP vendor) could handle the above
load without much problem...  though some scale better than others.
I assume they have a forum you can ask such questions in....

>Has anyone established the limits of the openLDAP server ?

In general, >10 write-ops/second and >100 read-ops/second is
achievable using CHEAP pc-clone hardware (with tuning/configuration
to avoid write syncs).  Scaling to 10M entries can be challedging.

>Or found ways to make it perform better under high load ?

See software list archives + FAQ.

>How about distributed setups with a caching proxy for example ? 

We don't have a caching proxy (yet).  We have replicas (with
caching).

Kurt