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

Re: Very slow search speed



Dear Igor,

In authentication part, I do not use FreeRadius authentication
configuration. Because I need some special features so I have to write my
own code and call it as an external program.


To bypass authentication request to my external program, I put this
configuration on FreeRadius’ users file.



DEFAULT Auth-Type := Accept

        Exec-Program-Wait =
"/usr/local/freeradius/radiusExternalProgram/bin/extAuth"



I bind ldap with manager’s dn and password. The search filters are

1. "(&(username=USERNAME)(realm=REALM))"

and

2. "(products=PRODUCT)"



On ldap, all users refer by ‘uid’ (= combination of ‘username’ + ‘realm’)
are under ‘products’ branch.



Paweena Charoentham




----- Original Message -----
From: "Igor Brezac" <igor@ipass.net>
To: <openldap-software@OpenLDAP.org>
Sent: Thursday, March 13, 2003 9:04 PM
Subject: Re: Very slow search speed


>
> Please provide your freeradius ldap related configuration.  In particular
> show filter and groupmembership_filter parameters.
>
> -Igor
>
> On Thu, 13 Mar 2003, Paweena Charoentham wrote:
>
> > I want to use OpenLDAP with FreeRadius but after some tests I have a big
problem with performance.
> >
> >
> >
> > For 1 client with continuously search using ldapsearch command the
throughput rate is only 3-4 requests/second. (There are about 600,000
entries on ldap) I also test by put only 10,000 entries on ldap but the
throughput rate is not different much.
> >
> >
> >
> > When I increase the number of simultaneous client continuously send
requests to ldap. The throughput rate sharply decreases. With 16
simultaneous clients, the throughput rate is 0.2 request/second. Over 16
clients, OpenLDAP will saturate.
> >
> >
> >
> > I also write my own client program using OpenLDAP library to measure
which part drop the performance down. My client open connection to ldap, do
2 searches and then close the connection. After run it, I found that for
each search request, 66% of time spends on ldap_simple_bind_s function. Each
ldap_search_ext_s takes 16% and 2% for others.
> >
> >
> >
> > On this test I use OpenLDAP-2.0.27 on RedHat 7.3 machine, Intel Xeon 2
GHz dual CPU with 2 GB RAM, Adaptec SCSI host adapter (aic7899) on RAID5,
BROADCOM NetXtreme BCM5702X Gigabit Ethernet Adapter (on board). Number of
the data in the ldap is about 600,000 entries.
> >
> >
> >
> > The following is some tuning I made on slapd.conf
> >
> >
> >
> > threads             32
> >
> > concurrency       27
> >
> > loglevel             4
> >
> >
> >
> > # Indices to maintain
> >
> > index   objectClass         eq
> >
> > index   products             eq
> >
> > index   uid                     eq
> >
> > index   username,realm  eq
> >
> > index   mail                    eq
> >
> > index   domain               eq
> >
> >
> >
> > cachesize                      1000000
> >
> > dbcachesize                   1000000000
> >
> >
> >
> > (I also do this test on OpenLDAP-2.1.12 and the throughput rate is as
same as 2.0.27)
> >
> >
> >
> > While the test is running, the ldap server load is only about 2 and
there is some physical memory left. But I wonder why the number of threads
is always being 9? Why does it not increase to share works? Am I do
something wrong? Or what is the right way to tune OpenLDAP to gain an
acceptable performance with this enormous data? Anyone help me please…
> >
> >
> >
> > Paweena Charoentham
> >
>
> --
> Igor