cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: Cocoon 2.0 Scalability Disappointment
Date Sat, 01 Dec 2001 17:16:57 GMT
On Fri, 30 Nov 2001, Gianugo Rabellino wrote:

> 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
> more.
> > 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?

I had a talk there about the pooling messages as they are important for
pool tuning. The consensus so far will be to use a different category to
log onto concerning this issue.

Anyway, with the logkit management system you are able to configure each
component to the logger it should get and thus you can easily
concentrate on a component base. But yes, Avalon itself (ie. Component
Managent System) doesn't behave that way. Today it is using the logger
passed into the ExcaliburComponentManager for all CM operations.

Maybe we should move this logging aspect to the Avvalon list.


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

View raw message