directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject [apacheds] FYI: Fwd: [SLAMD-Discuss] Can SLAMD do assertion tests?
Date Fri, 05 Aug 2005 02:59:38 GMT
This might be helpful for boys and girls who want to test ApacheDS. :)


---------- Forwarded message ----------
From: Neil A. Wilson <>
Date: 2005. 8. 2 오후 1:10
Subject: Re: [SLAMD-Discuss] Can SLAMD do assertion tests?

On Mon, 2005-08-01 at 22:49, Trustin Lee wrote:
> Hi,
> I'm trying to use SLAMD to test my Apache Directory Server
> Multi-master Replication module. I want to load some sample data and
> perform random LDAP operations on multiple replicas and check all
> replicas have the same content. Can SLAMD be used for this kind of
> scenario?

No, it can't do this out of the box. However, it would not be difficult
to write a custom job to do something like this, provided that there is
some programmatic way to know what should be there (you could use
something like a subtree "(objectClass=*)" search on one server and
compare each entry on the others, but that would likely be less

Are you doing this as a means of verification or as a means of
performance testing? If you want to use it for verification, then SLAMD
may not be the best tool for that, at least by itself. However, Sun has
a utility called ldapcmp in the Directory Server Resource Kit (download
at, documentation
at that can do something
similar to this.

If you are trying to measure the performance with which changes can
propagate from one server to another, then SLAMD can do that, provided
that the Apache Directory supports the persistent search control. The
best way to do this is to do a normal job that performs write operations
and use it in conjunction with the replication latency resource
monitor. This monitor will register a persistent search against an
entry one one server and periodically modify it on another. The time
between the modification on one server and the persistent notification
on the other will be taken as the propagation delay (or replication
latency). Some of the jobs provided with SLAMD have this capability
directly, but the replication latency resource monitor is generally a
better approach because it is much more flexible (e.g., you can monitor
multiple servers by having multiple instances of the replication latency
resource monitor) and can be used with any job.

If the Apache Directory doesn't support the persistent search control,
then you would have to use a poll-based monitoring mechanism instead.
Many of the jobs in the "Identity Synchronization for Windows Job
Classes" group that interact with Active Directory use this kind of
polling mechanism since AD doesn't support the persistent search. Using
polling is less accurate and more resource-intensive than the persistent
search, but it is better than nothing.

> Thanks in advance,
> Trustin
> --
> what we call human nature is actually human habit
> --

For more information about the SLAMD Distributed Load Generation Engine,

To unsubscribe from this mailing list, send an e-mail message to

what we call human nature is actually human habit
View raw message