directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [ApacheDS] Performance testing
Date Fri, 30 Jun 2006 18:26:18 GMT

--- Alex Karasulu <> wrote:

> Hash: SHA1
> Ole you sure do have a lot of energy :).

When the people you are writing to are as bright as
everyone on this list, it's easy to get pumped :)
I try to talk to friends and family about how cool
this stuff is, and they all think I have completely
lost it!

> ...
> >> 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.

It's actually the maven archetype plugin that creates
the archetype starting point that is the definition of
a specific type of project.

When running the mvn archetype:create command we
this parameter 


thus maven creates a project that is the baseline or
type for all projects of this kind, the same way a
java class is the base type for all objects of its

Lets just say that an archetype is the same as a
project type or project class.

So when we are running mvn archetype:create with the 

option, maven creates a set of directories and files
that are the starting point for the definition of a
specific project type.

So to do the ADS archetype / project type

we would do something like this:

mvn archetype:create

This sets up a project that is the starting point for
defining a project of a new type.

So the analogy would be that this is what defines what
a .java file is or can be.
What is allowed to go in a .java file...or what does a
.java file compiler understand...what are the
rules/'s not a .java file, it's what
defines what can go in a .java file, the same way a
.java file defines what is an object of a .java file
type is allowed to store/do.

It looks like a maven project though with a pom.xml
in the root of the project directory.

However, there is another pom.xml, deeper in the
directory structure.

The pom.xml in the root tells maven that this is a
"template/baseline" for all projects of this type.

The other pom, described in

is the pom that will go in the root directory of all
the projects that the current archetype project

So it's a 2 steps process.

First create the project baseline set of directories
and files and use mvn to install it.

Then run mvn archetype:create with the
archetypeArtifactId for that project type, and maven
creates the starting point for us every time.

So in the first step we used the 


parameter to get us the starting point for the
starting point.

Then we finished the starting point, installed it,
and now we are using the 


to create the starting point.

> > 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?

The mojo could do that, via the command line, or a
nice eclipse plugin...although for 1.0 hand editing
would probably suffice...the important thing is that
everyone has the same starting point, and we can
generate a quick diff on it, to do comparisons between
different performance testing projects.  This way
since everyone is familiar with the baseline, everyone
should be able to understand the diff from the
baseline quickly and understand and interpret the
performance testing results correspondingly.

> > 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.

Yeah I have not seen an archetype specifically for
performance testing anywhere, so we'd probably be
breaking some new ground here.  Gotta give the maven
developers credit for the leap forward here.  It's a
pretty brilliant way of thinking about managing the
various pieces associated with a project.  Each
project type produces a specific deliverable.  It's
easy to see hwo it relates to other project
deliverables through the dependencies and how it is
used.  Thus everything is broken down into lots of
little lego blocks.

> > 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

>Perhaps I can setup something in the sandbox for us
to >play with these

>Still though I'm open to multiple approaches.


A sandbox would be great - perhaps with different root
directories for each type of approach.  Each approach
that's taken in this type of problem space would
complement another one would think.  That also lets
everyone try out the approach they like best or are
most comfortable with, while keeping pace with and
contrasting it to other approaches.

OK - Gotta get ready for Italy vs. Croatia!

- Ole

=== message truncated ===

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

View raw message