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? Ciao, -- Gianugo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
