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

Re: poor performance of Openldap/Pgsql-7.4.1



> Hi
>
> I installed OpenLDAP-2.2.11/PgSQL-7.4.1 on Solaris9.
>
> After I added one thousand entries, although I tuned up parameters of
> postgresql.conf,  used directorymark tool to test the performance of
> ldapsearch, the results was only  1.7ops. It was very poor.
> (By back-bdb with same entries, I got 387.8ops. )

By definition, back-sql should not be considered a replacement of any
native storage backend, e.g. back-bdb.  Read
http://www.openldap.org/faq/data/cache/378.html for details.  Any
performance comparison would be unfair and useless.

>
> Information of my entries like:
> ------------
> dn: cn=zhang(0-1000),o=sql,c=RU
> objectClass: top
> objectClass: inetOrgPerson
> cn: zhang(0-1000)
> sn: pu
> o: sql
> uid: (0-1000)
> mail: zhang@sql.com
> employeeNumber: (0-1000)
>
> I used all of default sql files under /back-sql/pgsql/ to create the
> data store, but  only added one line in testdb_create.sql as below.
> ------------
> CREATE UNIQUE INDEX PK_authors_docs ON authors_docs (pers_id,doc_id);
>
> Has anybody gotten high performance by postgresql?
> Would you please give me suggestions?

I would suggest to add indices on all keys, if you didn't yet.

>
> Another question:
> Does back-sql support all of matching rules of RFC?

No.  It tries to do its best with some of the matching rules; in some
cases, to be conservative, it gives up applying matches at the SQL level
and returns candidates, leaving the matching rule application to slapd; in
other cases it simply gives up.  For instance, if you map a value of
"My  Name" (note the double space; quotes are not part of the value) to a
"cn", the exact match will always fail, because slapd normalizes it
to "My Name" (note the single space).  This could be removed at the
expense of a much higher overhead, because all the occurrences of
"special" chars, e.g. spaces in attributes with directory string syntax,
should be replaced by "%" and substring ("like") assertions should be used
even for exact matches.  This is what is done, for instance, for
attributes with telephone number syntax, so that a telephone number "001
234 5678" matches "0012345678" as well as "#001-234-5678".  If there's
anything special you need, and you think it could be of general use, feel
free to discuss it on -devel.  back-sql is experimental, in the sense that
there is still a lot of work to do about it.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it




    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497