solaris8 openldap and iplanet4.1

[Stan Francis <scfrancis@tribuneinteractive.com>]

We have openldap-2.1.21 running on solaris8. We're using Iplanet4.1 web server 
as a front end to our application. It appears as if Iplanet upon
initial login as well as subsequent ACL Cache updates iterates through all
possible groups for the specific uid attempting to match them one by one. Even
under relatively light traffic it causes high CPU usage of slapd and inermitent 
CPU spikes.

Is this a result of 'dynamic groups' or is there some index I'm missing?
Any help is appreciated.

-- the filters used for the search:

Sep 30 08:31:54 host slapd[28007]: conn=3 op=4 SRCH base="dc=tribuneinteractive,dc=com" scope=2 deref=0 filter="(|(&(objectClass=groupOfUniqueNames)(|(uniqueMember=uid=sfrancis,dc=tribuneinteractive,dc=com)))(&(objectClass=groupOfNames)(|(member=uid=sfrancis,dc=tribuneinteractive,dc=com))))"
Sep 30 08:31:54 host slapd[28007]: conn=3 op=4 SRCH attr=cn
Sep 30 08:31:54 host slapd[28007]: conn=3 op=4 SEARCH RESULT tag=101 err=0 nentries=2 text=
Sep 30 08:31:54 host slapd[28007]: conn=3 op=5 SRCH base="dc=tribuneinteractive,dc=com" scope=2 deref=0 filter="(&(cn=trb.tii.httpd.o2)(|(objectClass=groupOfUniqueNames)(objectClass=groupOfNames)(objectClass=groupofurls)(objectClass=groupofcertificates)))"


-- snippet from logfile:

>>> dnNormalize: <uid=bscott,dc=tribuneinteractive,dc=com>
=> ldap_bv2dn(uid=bscott,dc=tribuneinteractive,dc=com,0)
<= ldap_bv2dn(uid=bscott,dc=tribuneinteractive,dc=com,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=bscott,dc=tribuneinteractive,dc=com,272)=0
<<< dnNormalize: <uid=bscott,dc=tribuneinteractive,dc=com>
dnMatch -2
        "uid=bscott,dc=tribuneinteractive,dc=com"
        "uid=sfrancis,dc=tribuneinteractive,dc=com"
>>> dnNormalize: <uid=emoss,dc=tribuneinteractive,dc=com>
=> ldap_bv2dn(uid=emoss,dc=tribuneinteractive,dc=com,0)
<= ldap_bv2dn(uid=emoss,dc=tribuneinteractive,dc=com,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=emoss,dc=tribuneinteractive,dc=com,272)=0
<<< dnNormalize: <uid=emoss,dc=tribuneinteractive,dc=com>
dnMatch -3
        "uid=emoss,dc=tribuneinteractive,dc=com"
        "uid=sfrancis,dc=tribuneinteractive,dc=com"
.......
ldbm_search: candidate entry 447 does not match filter


-- slapd.conf

include         /opt/apps/ldap/etc/openldap/schema/core.schema
include         /opt/apps/ldap/etc/openldap/schema/cosine.schema
include        /opt/apps/ldap/etc/openldap/schema/inetorgperson.schema
include         /opt/apps/ldap/etc/openldap/schema/trbtii.schema
include         /opt/apps/ldap/etc/openldap/schema/iplanet.schema

schemacheck     on
sizelimit       5000
#loglevel       256
idletimeout     30

allow bind_v2

database        ldbm
cachesize       1000
dbcachesize     200000
suffix          "dc=tribuneinteractive, dc=com"
rootdn          "cn=Manager, dc=tribuneinteractive, dc=com"
rootpw          XXXXXXX
directory       /opt/apps/ldap/var/oxygenpui
index   default         pres,eq,sub
index   objectClass     eq
index   uid             eq
index   C
index   cn


Thanks,
Stan Francis