cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: benchmarking Cocoon?
Date Sat, 19 Apr 2003 16:15:32 GMT
on 4/19/03 4:42 PM Diana Shannon wrote:

> On Friday, April 18, 2003, at 07:15  PM, Geoff Howard wrote:
>>I put options in quotes because there aren't a lot of java-xml-
>>xlst options out there.  Of course, it's almost impossible to
>>do apples to apples comparisons against those, but it is
>>reasonable to try.  If Cocoon takes 100 times as long on average
>>per page, it's not a viable option for people.  If it's fast, but
>>needs 10 times the memory, same thing (although memory is cheap now).
> Although memory is cheaper, I think the cost of Cocoon/Java hosting, 
> with higher RAM requirements, remains a limiting factor in adoption for 
> small sites/limited budgets. In spite of the elegance of what Stephano 
> recently demo'd for a small site on this list, for my low-budget 
> clients, I'll probably stick with the current Forrest approach to 
> generate static pages, with all dynamic capabilities implemented in 
> php/perl/python (perhaps even generated by a modified Forrest). Clients 
> simply don't understand -- no matter how clearly you explain the 
> benefits -- why they should have to pay more than $10/month for hosting. 
> Perhaps dynamic sites created with small budgets (by people like me who 
> don't want to manage a server just to host client sites affordably) 
> aren't Cocoon's niche.

You are very right. In fact, my own father wouldn't have spent more than
that! (he doesn't know what cocoon is, nor cares, in fact) I would have
installed a local server here and upload nightly a statically generated

Still, this has nothing to do with cocoon. Static hosting is *much*
cheaper than anything else. Being able to 'nightly push' a
moderately-infrequently-updated web site from a local dynamic
cocoon-driven poor-man-cms solution

>>The first word out about Cocoon seems to be "neat but really slow
>>and a memory hog".  I wasn't around then, but it sounds like that
>>wasn't far off with Cocoon1.  If things have changed (as it sure
>>seems it has), it wouldn't be bad for business to "publish" some
>>kind of quantitative tests that prove that.
> I encountered the "memory hog" accusation during the early days of 
> Cocoon 2.0's release -- not during my Cocoon 1 days. I think a lot of 
> this came from those early untamed samples. I think the impression 
> persists.

Interesting enough, Cocoon 1.x used *way* more memory than Cocoon 2.x
but nobody really noticed because this memory went in and out (all the
DOMs being created and destroyed). Cocoon 2.x uses memory much more
agressively but the amount of garbage generated at runtime is very small
 (and even better with XSLTC). But all this is tunable!!!

Also, cocoon 2.x has a much better cache, but this requires more memory
to operate nicely.

This said, I think it's entirely possible to tune cocoon to use no more
than 2/3mb of RAM. This means turning off all caching, lower object
pooling, etc. all this can be done tuning cocoon.xconf and your sitemap.

maybe it's our fault to ship cocoon with "ready for" setting and
should aim a little lower than that!


View raw message