On Friday 23 November 2001 02:38 pm, you wrote: > Next we started a project to perform migration to Cocoon 2. I think we use > all mechanisms (at least the ones I know) to create a site that performs > well. But... under heavy load, the performance of the Cocoon 1 site remains > stable (slow but stable) and the Cocoon 2 site collapses. The initial > performance of the Cocoon 2 site is higher, but under "heavy load", it will > not do very much anymore. > > Mechanisms we used: > - Split pages in multiple parts based on caching posibilities. Ie. parts > that can use the same cache strategies (ie same key and validity) are > grouped together. > - The parts that can be cached are also translated to HTML using XSL as > much as possible. > - The XSL files are kept as small as possible. We tried to minimize the > amount of templates (initially there were about 60 templates).
We just did load testing on our application here a few weeks ago. Things to look for: * Run in debug mode and look for "decomissioning instance of" messages. That means that an object pool's maximum size is not large enough and it has turned into a factory. Creating & destroying objects for each request *kills* performance. * Watch the cachability in logs, and make sure things are being fed from the cache. All of our pages are dynamic, and such, none of them can be cached 100%. I was err'ing in inserting the dynamic data in the generator -> BAD!! The I18nTransformer is fairly slow and pages were taking 10s on average to come out of cocoon. I reorganized our pipeline and did as much as I could up front and cached it (similar to what you said above) and its down to 500ms-2s depending on page size and complexity. Its "fast enough" now, but the next thing I was going to look at was a GZipSerializer to compress the data going over the wire. I'm not sure how else to compact down a selectbox with 500+ entries, its just a lot of data :) * Move static content out of Cocoon's control. I got a *huge* user-perceived speedup by moving our static content out of the Cocoon servlet context and into its own context (just letting Tomcat serve directly). An even better approach would be to use a front-end webserver to serve the static, but installing Apache + tomcat + our app would be a bit much wen tomcat + our app is doing fine. On a side note, we deployed our Cocoon-based application at our first customer last week and it all went very smoothly! Kudo's to the dev team for making such a solid product :) -pete -- peter royal -> [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
