directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [ApacheDS] Performance testing - Next Steps
Date Tue, 04 Jul 2006 18:47:05 GMT
Hey Guys,

I just put together a next steps section in the
documentation.apt document.

If you like looking at the HTML version of the apt
document, just take this text and paste it at the end
of the document.

Then run mvn site.

Here it is:

* Next Steps

** Update the dependencies on the
ads.performance.archetype testing

     Add the ADS api project dependencies to the
dependencies list of the performance.testing.archetype
     This is so the unit tests can access the API.

** Create one or more baseline LDIF file(s)

    The performance.ldif file in the input directory
is currently empty.
    One or more of these files should be created, such
that the unit
    tests can run them.
    We were also discussing creating a mojo that can
generate these files, or
    using SLAMD.  It would be great to have a mojo
that just wrapped SLAMD,
    that way the we can just create another input
directory for the file
    SLAMD uses to generate the LDIF files, and this
would automatically
    be run during the generate sources phase of the
maven lifecycle.

** Create the ADS Testing Setup
    The following setup should be done in the public
void SetUp() method of each unit test contained in the
peformance.testing.archetype archetype.

    * Create an instance of the server.xml
configuration contained in the archetype input
    * Create an instance of ADS.
    * Configure the ADS instance with the server.xml
    * Configure the ADS instance with the server.xml
    * Run each unit test with the configured ADS

** Write the ADS Unit Tests

   I think there are unit tests already, so now we
just need to sanitize them so that they provide a
   starting point, and put them in the archetype's
unit testing directory, along with, 
   which is currently just the default test that comes
with any generic maven project.

** SLAMD LDIF Generation mojo Command

     The command below will create a baseline for the
ldif generation mojo:
     mvn archetype:create

** Completing the Mojo

    The mojo needs to perform the following activities
(This is rough):
    * Read the configuration file for generating the
ldif files (Delegate to SLAMD)
    * Generate the files (Delegate to SLAMD)

*** Creating another directory for the SLAMD
configuration file(s)

    Please see the general instructions for creating
the performance testing archetype.
    For now we'll assume we have the directory
    available, and that it contains a baseline
configuration file for generating ldif file(s)
    called "slamd.cfg".

*** Specify the location of the SLAMD configuration
files in the mojo

    private static final String
    private static final String

*** Binding the Mojo to the maven lifecycle in the
performance.testing.archetype archetype  

    The ldif.generation.mojo now needs to be bound to
the maven lifecycle's generate source phase.
    This is done in the code of the mojo:
     * @goal generate
     * @phase generate-sources
     * @description Generates the ldif file(s) and
puts them in the ldif input directory
** Updating the pom of the
performance.testing.archetype archetype  

    Open the
src/main/resources/archetype-resources/pom.xml and add
the following build section right under the
dependencies section
    (I think ADS is using JDK 1.5, so I added that to
the configuration of the compiler plugin - this should
be set to the 
    version of the JDK used):
* Testing the Mojo with the performance testing

    The process is the same as before.  We do:
    mvn archetype:create
    However, now before we run tests the mojo will
create the ldif files for us.
    Thus the file names that the mojo creates, must be
used in the setup of the 
    This would make it attractive to perhaps create
multiple archetypes for 
    specific tests, that are just slight variations of
    That way we don't need to change too much stuff in
the setup section 
    of each testing project.

--- Alex Karasulu <> wrote:

> Hash: SHA1
> Ole you sure do have a lot of energy :).
> ...
> >> Hmmm I see where you're going.  You want to
> generate
> >> projects that have
> >>  a server.xml that can be customized for the test
> >> case.  What about
> >> having test cases for embedded operation where
> the
> >> server.xml does not
> >> come into play?
> > 
> > There can be 2 separate archetypes for these
> cases.
> ...
> > But, what if it did'nt have everything we wanted
> in
> > the starting point for this project.
> > 
> > We just create a maven project using the archetype
> > plugin, which is passed as a parameter to the
> > archetype:create command and this project creates
> a
> > project that is the starting point for creating
> other
> > projects of a specific type, just like a .java
> file is
> > a means of creating an object of a specific type.
> So your archetype creates maven modules that are
> themselves archetypes?
>  Hmmm from below this does not seem to be the case.
> > So now we can go ahead and create a project
> starting
> > point (directories and files) that we will create
> over
> > and over again whenever that specific starting
> point
> > is needed.
> > 
> > So sometimes we want to manipulate the server.xml
> > file, 
> > 
> > I'm just going to interrupt myself here for a
> > minute...there should be an outuput directory that
> > captures the diff/patch to the server.xml from the
> > starting server.xml...ok...continuing
> So the archetype changes the initial prepackaged
> server.xml by asking
> the user questions?
> > so there's one specific archetype for that type of
> > project, and sometimes we just want to configure
> > programatically, so we don't need the server.xml,
> so
> > we could make a different archetype for that type
> of
> > project, although since having a directory with
> > server.xml in it does not inter with programmtic
> > configuration, it might be easier to just explain
> in
> > the documentation that the server.xml is
> there...and
> > that it can be used, or ....  can be used to
> configure
> > ADS.
> Ok
> > So when testing ADS the developer would run
> > mvn archetype:create .... followed by the specific
> > parameters for creating an ADS testing project.
> > 
> > This ensures that everyone testing ADS starts with
> the
> > same inputs.
> > 
> > Someone mentioned generating LDIF files.
> > 
> > To do this we could create another input directory
> > in the archetype that contained a file with some
> > configuration parameters for generating the LDIF.
> > 
> > That way everyone just has to specify that file
> for
> > apples to apples comparisons.
> Following ...
> > Similary, there could be a distributed client
> > configuration input file that coordinates multiple
> > clients that are hitting ADS, along with a
> > corresponding mojo for executing that.
> +1
> > That file would store things like network
> > configuration params, hardware on client(s),
> hardware
> > on ADS server, thus also providing the apple for
> > comparison.
> > 
> >> Thus there should be one
> >>> archetype per DS.  So apache would have one, and
> >>> OpenLDAP would have another.  
> >> Ok I see now.  The OpenLDAP archetype is a bit
> more
> >> difficult to pull
> >> off tho since it is C-code and not embeddable or
> >> launchable via test
> >> cases.  We might have to fork an instance of it.
> > 
> > Yeah - I just through this into the mix, since one
> of
> > the goals was to compare results with other
> servers.
> > 
> > If I had to do it right now I would just run
> OpenLDAP
> > on a "Sterilized" server that I'm also running
> apache
> > ds on and then point OpenLDAP to the configuration
> > files in the test directory...which I'm just
> assuming
> > is possible.
> > 
> > Then code that archetype's mojo to perform testing
> in
> > a way that is as close to the ADS mojo as
> possible, or
> > precisely the same as the ADS mojo, by making
> perhaps
> > using the same mojo executing the same JNDI code
> on
> > both servers.  Thus the only difference would be /
> > could be configuration server configuration.
> > 
> Right there is a distinction between server setup
> and tests which should
> be reusable on different servers.
> ...
> > So we are starting with the same inputs, we can
> have
> > many projects that only do performance testing,
> but
> > change the inputs in various ways, and this is
> clean
> > and easy to see, because all the projects have the
> > same structure.
> I like this project structure consistency.  I just
> never thought of
> making a new maven project for each kind of test. 
> But it does make sense.
> My ass backwards thinking was stuffing everything
> into a base JUnit test
> case and extending that for a set of performance
> tests.  Then using a
> maven profile to just run the performance tests. 
> And at times this
> won't make sense since we need to bombard the server
> with serveral
> clients.  Meaning the project just launches an LDAP
> server rather than
> running a simple unit test and getting the results. 
> The test may never
> end.  An archetype and plugin does break things down
> better.
> > For instance we might have a single performance
> > testing project that gets updated and rechecked
> into
> > subversion, but now someone would have to go back
> in
> > time through subversion to see how inputs have
> changed
> > over time, rather than just comparing each
> project.
> Makes sense.  The maven peeps have each integration
> test as a separate
> maven project module.
> > So we would never check out a performance testing
> > project, change something, run tests, and check it
> > back in, unless we wanted to have that project as
> a
=== message truncated ===

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

View raw message