[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: update on: Re: thread problem OpenLDAP 2.1.8 + Solaris 9
I am able to get 800 queries per second on Netra T1 (440Mhz 512MB of RAM),
Solaris 9 (latest recommended patches), opendlap 2.1.8, BDB 4.1.24.
I used DirectoryMark benchmark tool -
http://www.mindcraft.com/directorymark/
I setup a simple access list (access to * by * read) just for testing
purposes, database size was 50000, I used 50000 random generated queries,
25 clients queried the ldap server. BDB cache size did not show any
performance difference with this dataset. I tried default and 256MB.
loglevel was 0. In my previous testing, ldbm database showed roughly
30% slower performance.
openldap ran solid without any faults, dropped connections or incomplete
queries. Load was very high on the ldap server, but this was to be
expected with this type of load put on the ldap server.
-Igor
On Tue, 12 Nov 2002, Thomas Nau wrote:
> Hi all.
>
> I ran a couple of tests today with OpenLDAP 2.1.8, BDB 4.1.24 and Linux
> 2.4/Solaris 9.
>
> Both behave the same so by now I don't think about this being a thread
> problem anymore. I removed all not required libs like OpenSSL and SASL but
> this didn't change a thing. The backend ist still ldbm. As a testcase I
> used a pre-created list of filter expressions (about 1000) which were send
> to the LDAP server via 'ldapserach -f ...'. The only ACL in place was
> read-access to anyone. Logging was disabled.
>
> Sending the requests from a one client to the server on a big SMP showed a
> CPU utilization on the server of close to 100% and the test finished in
> about 26 seconds. Using 2 clients in parallel (started on another SMP)
> raised the servers CPU utilization to about 190% but each of the client
> processes required 48 seconds. I expected it to be about 26-30 again as
> the requests are independent from each other. Trussing the server on
> Solaris showed that after the first run almost no reads to the DB files
> where issued anymore so IO performance shouldn't cause this. On the other
> hand there have been tons of timer() and yield() syscalls.
>
> Would some of the developers please enlighten me about what's going on and
> in which way the server takes advantage of SMP systems? Are there any
> tunables for it?
>
> -----------------------------------------------------------------
> PGP fingerprint: B1 EE D2 39 2C 82 26 DA A5 4D E0 50 35 75 9E ED
> Phone: +49 731 50 22464
> FAX: +49 731 50 22471
>
>
--
Igor