cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinh...@apache.org>
Subject [RT] Performance Block
Date Sun, 28 Sep 2003 14:28:38 GMT

If I present Cocoon I'm always asked three questions:

 - Is it stable?
 - Is it easy to integrate it into my environment?
 - Does it perform well?

I don't have problems to answer question one and two - Cocoon has been
stable for years and there is always an easy way to integrate it in
existing environments.

But I find it more difficult to give an answer on question three. In my
projects performance issues have always been solved but this information
is not very helpful if somebody evaluates Cocoon.

To come up with any performance figures is not difficult - however to
provide meaningful, standardized statistics much more. 


Proposal
--------

I know it's not possible to provide the "definite truth" on the
performance of any technology and sometimes it's really funny to read
performance reports (e.g. J2EE Petstore vs .NET Petstore, or my database
is faster than yours ...) but it should be possible to give people an
idea in which *dimension* Cocoon can compete, not more. 
(I'm not afraid that Cocoon can't compete with compareable technologies
but I don't want a comparision of apples with oranges like the already
mentioned Petstore story where Sun's example wants to show patterns and
M$ has optimized it on speed. I could do the same with Cocoon if I
generate HTML with my JXTemplates without any further transformations ;)
)

Following all those considerations I want to propose the creation of a
new "performance" block that is ready to use for load tests - it should
contain:

 - one or more sample applications following Cocoon design patterns
 - performance optimized Cocoon configuration
 - JMeter integration
 - new Ant build target that creates all necessary things
   to run a test within the user's environment:
   * container (Jetty)
   * application
   * JMeter including the test script
   

 ... and the user can enter 
 - how much memory he wants to provide for the test
 - the number of concurrent users
 - the duration 
 and the cocoon.xconf, the various pool sizes and the settings 
 for the JVM are set accordingly.


What is this performance block good for?
----------------------------------------

 - We have an answer for the many performance questions.
 - Cocoon users will get a first impression on the performance
   of Cocoon in *their* environments
 - We can compare different Cocoon versions with each other!
   (e.g. we will see the performance improvements the Fortress
    migration will bring in 'ms' ;) )
 - We may find problems that only appear under high load.


What would be reasons against this block?
-----------------------------------------

 - We open the door for "apples to organges" comparisons.
 - This test can't use all the possible performance optimizations
   that are not part of Cocoon itself (caches like squid, OS
   specific things, ...)

Comments? (Up to now not a sinlge line of code has been writen - 
at least not by me ...)

Cheers,
Reinhard




Mime
View raw message