Add flag to matching rules to indicate if DN folding is needed.
Don't specify dnPretty as pretty function for DN attribute types as
this works too well (it breaks tests).
treated as a request for all required and allowed attributes of the class.
This allows:
ldapsearch (objectClass=*) inetOrgPerson
(requests return of all attributes of inetOrgPerson)
and
ldapsearch (objectClass=*) extensibleObject
(requests return of all attributes, e.g., "+" "*")
instead of just the id2entry db. It helps. I also found that tweaking the
environment (set_lg_bsize 2MB; set_cachesize 2MB) helps but those can be
taken care of in a DB_CONFIG file. Tweaked the bdb_bt_compare function; it
really only needs to be set on little-endian machines. (On big-endian machines
a lexical sort gives the same result as an integer sort.) Moved the final
checkpoint back to the dbenv_close, I think this leaves a cleaner log file.
overflow/fragmentation. (This is now 16K vs default 4K.) It turns out
that the entries' on-disk format is quite space-inefficient, storing
4 bytes per pointer or integer when typically >50% of those bytes are
zero. Oh well. It's about a 2:1 space increase over ldbm now, vs 4:1
before when all the entries were overflowing the 4K pages.
now take only two arguments instead of 3, overwriting the result onto the
first argument. (glibc2.0.7 defaults to a 2MB stack per thread; 3 IDLs at
1.5MB plus various other runtime overhead is enough to trash the stack.)
Also pass in a tmp IDL from search_candidates instead of allocating it in
each candiate function.
compile cleanly when BDB_FILTER_INDICES is defined, but I have not
yet seen whether any of it actually works. In particular, I don't
understand the "range" argument to the candidate functions...
Includes rewriting of URLs where the DN of the referral object
and the DN of the ref attribute attribute are not the same.
Also, always returns explicit DN and scope.
Currently, back-ldbm only. Needs to be ported to back-bdb.
Developed by Steve Omrani/IBM
Copyright IBM Corp. 2001
Use of this source code is subject to the terms of The OpenLDAP
Public License Version 2.7, 7 September 2001. No trademarks of the
IBM Corporation are to be used to identify, endorse or promote any
products derived from this code without the prior written consent
of IBM.
Use presence indices in support of >= and <=.
(Note presence indices could be used to support = and substr in
like fashion where eq and substr indices are not maintained, but
I'll save that for another day.)
Developed by Julius Enarusai/IBM
Copyright IBM Corp. 2001
Use of this source code is subject to the terms of The OpenLDAP
Public License Version 2.7, 7 September 2001. No trademarks of the
IBM Corporation are to be used to identify, endorse or promote any
products derived from this code without the prior written consent
of IBM.
in a check. This way you have to say:
index userCertificate eq
If we remove it, we could say:
index userCertificate;binary eq
I have not tried the latter.
you can search efficiently the directory for a certificate.
Notice that we index certificates just as serial integers. A full
index should combine the issuer DN too, but I think in most scenarios
that would be extremely redundant and of little benefit. We can add
an option later to do full indexing.
Apparently, we refuse to index ;binary attributes. That is mostly
bogus. Whether it is indexable or not depends on whether we know how
to or not, nothing more. I.e., the existance of indexer and filter
functions for the matching rules that are relevant to the attribute
type.
values as stored in the entry on the one hand and an assertion value
that is not necessarily of the same syntax. So tell value_match this
is the case by setting SLAP_MR_VALUE_IS_IN_MR_SYNTAX in flags.
if needed. This is controlled by SLAP_MR_VALUE_IS_IN_MR_SYNTAX,
a new flag that should be set when evaluating filters such as in
searches and compares and unset otherwise (such as in modify).
Now, some callers of value_match, notably value_find, don't know
whether to set it or not. We'll see to that.
Changed AttributeDescription.{ad_cname,ad_lang} to struct berval everywhere
Deleted ad_free() everywhere
Added ad_mutex to init.c
The AttributeDescriptions are in a linked list hanging off of the
corresponding AttributeType.
error reporting to client and syslog. And indexing, of course.
Now, the problem is that matching rules get called from different
places that are inconsistent in what an assertedValue is. When doing
a modify, a full certificate value is passed (to verify it isn't
already there). When doing a search or compare, the passed value is
in the syntax of the matching rule.
Consistency would require that the caller extracts an asserted value
from the full value before calling smr_match. It can do this by
calling smr_convert (it was unused, was it meant to be used for
this?).
Unfortunately, the caller is typically value_find, value_match, etc.
that have themselves little knowledge of what they are dealing with,
so their interface needs to be extended, new flag values or new
arguments, so that they know if they have a value in attribute type
syntax or in matching rule syntax.
to activate. The bdb_decode works in-place on the db data. Add/Search are
OK, I think Modify needs to be tweaked. Don't use this yet unless you want
to help finish it.
LDAP/UDP messages. Slapd marks received CLDAP messages as LDAP_VERSION2.
The client library can generate CLDAP queries if -Protocol 2 is chosen,
otherwise not. LDAPv2 CLDAP cannot query the slapd rootDSE, gets no reply.
Compile with -DLDAP_CONNECTIONLESS to use this code.
For slapd, use "-h cldap://" to listen on UDP.
For ldapsearch, use "-H cldap://" to query on UDP.
Client-side support is very minimal:
no automatic timeout/retries
no basedn wildcard expansion on results
no support for specifying multiple servers at once.
Summary of changes is cited below.
The patch still needs some cosmetic changes to be made, but is ready for testing.
-----Original Message-----
From: Sam Drake [mailto:drake@timesten.com]
Sent: Saturday, April 07, 2001 10:40 PM
To: 'mitya@seismic.ru'
Cc: openldap-devel@OpenLDAP.org
Subject: RE: Slapd frontend performance issues
FYI, here is a short description of the changes I made. I'll package up the
changes asap, but it may take a couple of days.
The performance numbers quoted in this report were seen at my location with
a 100,000 object database ... the slower numbers I mentioned earlier were
reported by a customer with a 1,000,000 object database.
I also can't explain the very poor performance I saw with OpenLDAP and LDBM
with a 100,000 object database.
...Sam Drake / TimesTen Performance Software
----------
Work Performed
OpenLDAP 2.0.9, including back-sql, was built successfully on Solaris
8 using gcc. The LDAP server itself, slapd, passed all tests bundled
with OpenLDAP. OpenLDAP was built using Sleepycat LDBM release 3.1.17
as the "native" storage manager.
The experimental back-sql facility in slapd was also built
successfully. It was built using Oracle release 8.1.7 and the Oracle
ODBC driver and ODBC Driver Manager from Merant. Rudimentary testing
was performed with the data and examples provided with back-sql, and
back-sql was found to be functional.
Slapd and back-sql were then tested with TimesTen, using TimesTen
4.1.1. Back-sql was not immediately functional with TimesTen due to a
number of SQL limitations in the TimesTen product.
Functional issues encountered were:
1. Back-sql issued SELECT statements including the construct,
"UPPER(?)". While TimesTen supports UPPER, it does not support the
use of parameters as input to builtin functions. Back-sql was
modified to convert the parameter to upper case prior to giving it
to the underlying database ... a change that is appropriate for all
databases.
2. Back-sql issued SELECT statements using the SQL CONCAT function.
TimesTen does not support this function. Back-sql was modified to
concatentate the necessary strings itself (in "C" code) prior to
passing the parameters to SQL. This change is also appropriate for
all databases, not just TimesTen.
Once these two issues were resolved, back-sql could successfully
process LDAP searches using the sample data and examples provided with
back-sql.
While performance was not measured at this point, numerous serious
performance problems were observed with the back-sql code and the
generated SQL. In particular:
1. In the process of implementing an LDAP search, back-sql will
generate and execute a SQL query for all object classes stored in
back-sql. During the source of generating each SQL query, it is
common for back-sql to determine that a particular object class can
not possibly have any members satisfying the search. For example,
this can occur if the query searches an attribute of the LDAP
object that does not exist in the SQL schema. In this case,
back-sql would generate and issue the SQL query anyway, including a
clause such as "WHERE 1=0" in the generated SELECT. The overhead
of parsing, optimizing and executing the query is non-trivial, and
the answer (the empty set) is known in advance. Solution: Back-sql
was modified to stop executing a SQL query when it can be
predetermined that the query will return no rows.
2. Searches in LDAP are fundamentally case-insensitive ("abc" is equal
to "aBc"). However, in SQL this is not normally the case.
Back-sql thus generated SQL SELECT statements including clauses of
the form, "WHERE UPPER(attribute) = 'JOE'". Even if an index is
defined on the attribute in the relational database, the index can
not be used to satisfy the query, as the index is case sensitive.
The relational database then is forced to scan all rows in the
table in order to satisfy the query ... an expensive and
non-scalable proposition. Solution: Back-sql was modified to allow
the schema designer to add additional "upper cased" columns to the
SQL schema. These columns, if present, contain an upper cased
version of the "standard" field, and will be used preferentially
for searching. Such columns can be provided for all searchable
columns, some columns, or no columns. An application using
database "triggers" or similar mechanisms can automatically
maintain these upper cased columns when the standard column is
changed.
3. In order to implement the hierarchical nature of LDAP object
hierarchies, OpenLDAP uses suffix searches in SQL. For example, to
find all objects in the subtree "o=TimesTen,c=us", a SQL SELECT
statement of the form, "WHERE UPPER(dn) LIKE '%O=TIMESTEN,C=US'"
would be employed. Aside from the UPPER issue discussed above, a
second performance problem in this query is the use of suffix
search. In TimesTen (and most relational databases), indexes can
be used to optimize exact-match searches and prefix searches.
However, suffix searches must be performed by scanning every row in
the table ... an expensive and non-scalable proposition. Solution:
Back-sql was modified to optionally add a new "dn_ru" column to the
ldap_entries table. This additional column, if present, contains a
byte-reversed and upper cased version of the DN. This allows
back-sql to generate indexable prefix searches. This column is
also easily maintained automatically through the use of triggers.
Results
A simple database schema was generated holding the LDAP objects and
attributes specified by our customer. An application was written to
generate test databases. Both TimesTen and Oracle 8.1.7 were
populated with 100,000 entry databases.
Load Times
Using "slapadd" followed by "slapindex", loading and indexing 100,000
entries in an LDBM database ran for 19 minutes 10 seconds.
Using a C++ application that used ODBC, loading 100,000 entries into
a disk based RDBMS took 17 minutes 53 seconds.
Using a C++ application that used ODBC, loading 100,000 entries into
TimesTen took 1 minute 40 seconds.
Search Times
The command, "timex timesearch.sh '(cn=fname210100*)'" was used to
test search times. This command issues the same LDAP search 4000
times over a single LDAP connection. Both the client and server
(slapd) were run on the same machine.
With TimesTen as the database, 4000 queries took 14.93 seconds, for a
rate of 267.9 per second.
With a disk based RDBMS as the database, 4000 queries took 77.79 seconds,
for a
rate of 51.42 per second.
With LDBM as the database, 1 query takes 76 seconds, or 0.076 per
second. Something is clearly broken.
