You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2003/09/28 16:28:38 UTC
[RT] Performance Block
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
Re: [RT] Performance Block
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 29 sep 2003, à 09:10 Europe/Zurich, Reinhard Poetz a écrit :
> ...The reason why I don't want the applications change is that I want
> to
> make them compareable...
I see you point - reference apps can be very useful in comparing
between versions, platforms, JDK releases, etc.
OTOH, performance testing of existing sample apps can be useful when
people want to know (for example) how many requests per second a given
pipeline or app can sustain in their current environment.
So I agree that both are useful.
>> ...Sounds good but the tester should also be warned that there
>> is more to
>> Cocoon tuning than just setting available memory.
>
> Yes, of course. A warning with a pointer to
> http://cocoon.apache.org/2.1/performancetips.html should do it...
Ok.
-Bertrand
RE: [RT] Performance Block
Posted by Reinhard Poetz <re...@apache.org>.
> From: Bertrand Delacretaz
>
>
> Le Dimanche, 28 sep 2003, à 16:28 Europe/Zurich, Reinhard
> Poetz a écrit
> :
> > ...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
>
> Wouldn't it be possible to include JMeter scripts in each block where
> one wants to test performance?
>
> Then, the performance block could find out which blocks are ready for
> performance testing and allow any of them to be tested.
>
> Would be more useful than "just" testing one or two sample apps IMHO.
Why not - I think this is a good idea! And I think we can have both: the
possibility to test each block and one sample block with a set of
applications that don't change but which can re-implemented with another
similar technology: e.g. One application uses js-flowscript and the
other uses apples or simple actions.
The reason why I don't want the applications change is that I want to
make them compareable.
>
> > ... 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...
>
> Sounds good but the tester should also be warned that there
> is more to
> Cocoon tuning than just setting available memory.
Yes, of course. A warning with a pointer to
http://cocoon.apache.org/2.1/performancetips.html should do it.
Reinhard
Re: [RT] Performance Block
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Dimanche, 28 sep 2003, à 16:28 Europe/Zurich, Reinhard Poetz a écrit
:
> ...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
Wouldn't it be possible to include JMeter scripts in each block where
one wants to test performance?
Then, the performance block could find out which blocks are ready for
performance testing and allow any of them to be tested.
Would be more useful than "just" testing one or two sample apps IMHO.
> ... 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...
Sounds good but the tester should also be warned that there is more to
Cocoon tuning than just setting available memory.
-Bertrand