And certain searches are ??
a) half as fast
b) 1/10th as fast
c) so slow I've never waited for them to complete.
>As far as I know Quipu it's optimized for searches for name parts
>(means searching for attributes which are part of the DN). Searching =
for
>other attributes could be a performance decrease.
>In my C-ISAM-based X.500 server you can put indizes on attributes of
>your choice. The same is possible with slapd (and, for example, gdbm).
Thanks, that's good to know.
Do you know how an RDBMS (like informix or Oracle or SQLServer) wiith an =
index on an attribute compares in its search completion time to your =
C-ISAM search with an index on that same attribute?
In other words, does x.500 or LDAP have any deleterious effects on the =
search retrieval or does the speed of the RDBMS pass straight through?
And finally, does the x.500 server you use create the tables in your =
RDBMS or do you need to map the DIT yourself to the RDBMS?
>Me too. My general impression is that current X.500 implementations are =
not
>optimized for performance - a well-designed RDBMS will be faster than
>a X.500/LDAP server.
>I feel that performance is an important topic - most companies do have =
a RDBMS
>containing data of their employees, and you can't convince them to use
>X.500/LDAP if there are significant performance disadvantages - even if
>X.500/LDAP has other advantages.
I'm with you there.
The problem with promising interoperability and distributed capacity as =
a trade off for performance is that the former benefits are meaningless =
if the applications that can take advantage of the directory service are =
bottlenecked severely by the directory service itself.=20
No one wants to wait for the switches to click at the telephone company. =
Infrastructure gets no respect <g>.
N
______________________________________
Neil Spiegel=20
Atlas Consulting Inc -- Toronto, Ontario Canada
V: 416-534-9792 F: 416-534-7888 =20
nspiegel@sympatico.ca