The performance of LDAP is satisfactory for most applications. In this section,
we compare the performance of DAP and LDAP in four areas: response time
to queries; the size of queries; PDU encoding speed; and the size and complexity
of client-side implementations. For these comparisons, we used our LDAP
implementation and the ISODE DAP implementation. The same DSA was used for
all query measurements, providing a baseline for comparison.
Table 1 shows the performance of a range of typical DAP and LDAP queries.
The tests were conducted on a dedicated machine running the DAP and LDAP
clients, the LDAP server, and the DSA. As can be seen in the table, the
delay introduced by LDAP is minimal. This delay could be eliminated altogether
by a native DSA implementation, eliminating the intermediate encoding, decoding,
and protocol translation.
Searches were performed using the same DSA, with a "hot" cache
of entries. Times are in milliseconds.
Table 2 shows the size of the queries and results given in Table 1. It
shows that LDAP queries are substantially smaller than equivalent DAP queries.
The savings are due primarily to the simplified DN and value encodings.
Query sizes are also reduced by the absence of service controls in every
operation.
LDAP queries are significantly smaller than their DAP counterparts. Query
sizes are in bytes.
Tables 3 and 4 show the time to decode and encode a range of typical
DAP and LDAP PDUs. They show that LDAP has a modest performance advantage
for simple PDUs and a substantial advantage for complex PDUs, especially
those containing many distinguished names where the LDAP string representation
is a big win.
LDAP protocol elements are easier to decode, especially for complex PDUs.
The complex PDU contained an attribute with over 600 DNs. About half of
the DAP decoding time was spent in a duplicate check, to ensure that an
attribute has only one of each value.
LDAP protocol elements are encoded more efficiently, especially for complex
PDUs.
Finally, we compare implementation size and code complexity). Such a
comparison is anecdotal at best, given the wide range of programmer skills
and goals used in producing the implementations. However, some conclusions
favorable to LDAP can be drawn from the overwhelming advantage it has in
this area, as shown in Table 5.
The Directory Enquiries client was chosen for the size comparison. It can
be compiled to use either DAP or LDAP for X.500 communication. The code
complexity of the ISODE DAP and our LDAP client libraries were also compared.
We used two complexity measures. The first, a count of the number of semi-colons,
approximates the number of statements. The second, a count of the number
of "if" statements, approximates the number of code paths. In
computing both of these metrics, an effort was made to include only those
portions of code required to access X.500.
The DE client, which can be built using either DAP or LDAP, is used to
compare implementation size. Semi-colon count, which approximates the number
of statements, and "if" statement count, which approximates the
number of code paths are another measure of complexity. The comparison was
between ISODE-8.0 and our LDAP implementation.
