Thanks Irv!

Freundliche Gre / With kind regards

Matthew Langham


Competence Center Open Source
Klingenderstr. 5
D 33100 Paderborn

voice  +49 5251/1581-30
fax    +49 5251/1581-71


From: Irv Salisbury []
Sent: Monday, December 05, 2005 5:06 AM
Subject: Re: Resource comparison between Cocoon and Struts/JSP??

It is really difficult to compare a JSP/Struts solution with a cocoon solution without knowing how many users, what types of things are taking place (like Hibernate, SQLTransformer, etc)  How much is Java, how much is XML, etc.  Do you have a lots of Javaflow?  As we have seen on this list the past few days, there are MANY ways to do the same thing in cocoon.

So, the best I can offer is our application we built and the resources we need.

It is primarily an app made up of CForms that use JavaFlow with the XML binding and our own modified SQLTransformer. (To add transactions and paging all in one component) (We started with flowscript and found it didn't work in the latest versions of Weblogic and Websphere, so beware!) We have about 175 CForms, a custom reporting engine built on cocoon, and about 250 total pages.  Lots of shared pipelines, aggregators, etc.  It is a product, and the whole thing is based on cocoon.

To have about 10 simultaneous users hitting the app, we have found server settings of 256 (min) and 512 (max) seem to work just fine.  The app does perform better if we use  512 (min) 1GB (max). 

Having been involved in apps using other technologies, I would imagine a more "pure Java" solution like JSP/Struts probably would require less memory.

However, the speed does rock in the app.  We have gotten comments on how well things perform.  As another comparison, our custom reporting engine is mostly XSL code and does perform better than the eclipse reports and similar to jasper reports on our report needs. 

I don't know how to quantify the CPU usage for you.  When the app is busy, the cpu is usually pretty pegged.  (At least it is using the CPU)

Sorry, that is the best I can offer.  I have not seen any major performance problems with cocoon, but have seen the memory usage a little higher.  Also, keep in mind that if you are doing a lot of XML, I have seen major differences in performance based on how well you write XSL.  Often, keeping performance in mind when writing XSL can make a 10x difference on large XML sets.  (And if you write a lot of cocoon apps you WILL have large XML sets :-)  The profiler can be your friend here when trying to track down where your app is taking the time.


On 12/4/05, David Crossley <> wrote:
Peter Hunsberger wrote:
> Matthew Langham wrote:
> >
> > We have a customer looking to build an architecture around Open Source
> > frameworks. He has asked us about the differences in needed resources (CPU,
> > Memory) when writing an application using Cocoon as compared to a Struts/JSP
> > solution. While I realize the answer is probably "that depends", there are
> > certain customers who just aren't interested in that type of answer :-(. And
> > this customer actually has to pay internal charges depending on the amount
> > of memory and CPU needed.
> >
> > So maybe someone out there has actually done this type of comparison or can
> > point me to something?
> Can't help directly, but be sure to point out that they should also
> factor in development and maintenance costs to get the total picture.
> Note that if you end up doing the testing yourself Cocoon will could
> loose unless you exploit caching.

We (cocoon-dev) should already know some of these
answers, at least at a basic level.

We now have where we run
our own Cocoon. We should have some "benchmark"
applications there, with a well-configured cache.
That should enable us to have actual values.

Of course it does depend on the actual application.

Another resource that we could develop would be
a set of documents which describe some different
application scenarios. Then ask the Cocoon community
to indicate the resources that they think these
applications would require. Document the average.

I wonder if some company should engage a few Cocoon
developers to initiate this framework, doing it as
part of the Apache Cocoon project.