cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Fiol BonnĂ­n <>
Subject Re: Performances analysis
Date Fri, 25 Nov 2005 21:20:52 GMT
2005/11/25, Jean-Christophe Kermagoret <>:
> Hello,
> I'm working on performances for the application of a client. And it's a
> little difficult to know which direction to take.
> I would like to define performance test guidelines that would permit to
> every cocoon developer to test its application and drive easily its own
> test. I read almost all the thread and documentation about performances,
> but I just found a few tips (and it's already a good thing). What I want
> is to analyze the cocoon code, and in more details, the cocoon portal block.
> To conclude, and because it's a reccurent question, I will create a wiki
> with all the information I will get here.
> Is there anybody that has already profiled Cocoon with JProfiler and
> JProbe. Are the results interesting ? What are the tools' limits ?
> Finally, what I'm looking for is a tool that will show me how many times
> a method is called, and how much it consumed. In a very naive approach,
> a simple log in each method would be helpful. A few times ago, somebody
> talked about AOP, have you heard about this thread ?
> I heard about JMX too, when people were thinking about removing
> instrumentation from 2.2. Has it been developed ?
> Thanks for all the tips.


We're about to go "live" with our first important cocoon application.
We created some JMeter tests and tested the scalability and stability
of our webapp. Much like we do with other webapps, not cocoon based.

We start with 1 JMeter thread (no thinking delays) and go up to as
many threads as we need to reach our maximum defined mean response
time for any request. This way, and with some statistics or load
estimations based on previous experiences, we can see how well our
apps scale.

For stability, we simply set a certain load (usually 1-4 JMeter
threads), and monitor some health params during a test which lasts a
6+ hours.

Specifically about cocoon, I can only confirm that caching is a real
"must" if you care about performance at all. Cache as many things as
possible... and even more. For example, we had trouble because we are
using the LDAP transformer, which is not cachable. We ended up storing
the (xslt-transformed) LDAP results in a file, and updating them
periodically in the background, so caching mechanisms are effective.
Maybe there are better options, but this one worked for us.

It's a completely different approach from yours, but I sincerely HTH,


View raw message