cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: Cocoon 2.0 Scalability Disappointment
Date Fri, 30 Nov 2001 18:19:10 GMT
Stefano Mazzocchi wrote:

> 3) they don't use a transparent proxy on top so the Cocoon cache is
> continously stressed.

If they are using XSP (or anyway are dynamically generating data) a 
transparent proxy won't help a lot: it will help the data flow (since 
Apache will be run on a fast network or even on a loopback) but not much 

> 5) they use XSP. I'm aware of performance issues with XSP load and
> execution under heavy load (some forgotten locking or synchronized
> method?). This is the place where I'd concentrate profiling effort.

So do I.

> 1) disable logging. If log is DEBUG, it could generate Gigabytes of
> information and disks could become the bottleneck.
> [I think log might be the bottleneck]

I think this can be an appropriate timing to start cleaning up the 
logging code. We have to find a policy and stick to it: I tend to say 
that we should *always* do a isDebugEnabled() or a isInfoEnabled() 
before spitting out Strings. I'm not that sure that such a policy should 
be enforced for levels of warn and above.

We should also come up with a sort of best practice/code convention 
about what should be logged at each level: from a quick look at the code 
it seems to me that many warnings and even some errors are logged at the 
debug level: this is to be avoided in all cases.

The next question is about Avalon: once we come up with a great logging 
policy we will we have control over Cocoon logging, but what about 
Avalon generated messagess ? Is the Avalon code itself "log wise" or 
will we end up with tons of debug strings being created anyway?



To unsubscribe, e-mail:
For additional commands, email:

View raw message