froehlich 02/03/25 09:08:26 Added: src/documentation/xdocs/drafts PerformanceGuide_draft.txt Log: added first draft of the Cocoon performace guide as plain text for review. Please review the draft and *patch* it! Revision Changes Path 1.1 xml-cocoon2/src/documentation/xdocs/drafts/PerformanceGuide_draft.txt Index: PerformanceGuide_draft.txt =================================================================== Common: ^^^^^^^^ - Logging kills performance. Consider disabling logging entirely from Cocoon (leave only the ERROR channel) and let Apache or the servlet container log accesses and stuff. - Use a transparent proxy in front of your web server! The fastest response is the one that is not even processed. Cocoon is *very* slow (compared to a proxy server) to read resources such as stylesheets and images. A transparent proxy (SQUID, for example, don't use Apache's mod_proxy because is not HTTP/1.1 fully compatible and disables connection keep-alive). Make sure you tune how long the static resources that Cocoon "read"s from the sitemap are cached (look into the readers code to find out more). - Consider prerendering or time-based batch-process the static parts of your site. PDF reports, rasterized SVG graphs or things that change regularly. - Fine-tune pool sizes for components in cocoon.xconf and sitemap.xmap. If pools are too small for the load, it greatly reduces performance. The goal is to achieve such configuration that for every request there is a free component in the pool. Suppose, you have up to 100 simultaneous requests, and your pipelines have up to 2 xslt transformers. Then, you need to have maximum pool size set to 200 xslt transformers. They will be created as needed and retained in the pool for future use. Note, that if you use large values for min pool size, it increases Cocoon startup time. - Consider following formula for Pipeline Processing: <Number of simultaneous users> * <depth of content aggregation>, - Consider following formula for Generators/Transformers/Serializers: <amount required to process one request> * <Number of simultaneous users> - Consider following formula for Connectors: <count of pipeline components to process one request> * <Number of simultaneous users> - For optimum performance with Tomcat 4 and Cocoon 2, use the HTTP/1.0 connector. - Move static content out of Cocoon's control. Move your 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. - Disable resource reloading. The disk I/O system could become the bottleneck. - Search for messages such as "decommissioning instance of...". This reveals some undersized pools which are corrected by tuning cocoon.xconf and sitemap.xmap. Undersized pools act like an object factory, plus the ComponentManager overhead. Pipelines: ^^^^^^^^^^ - Keep an eye on the overall complexity of pipelines. - Try to keep the size of the documents going through the pipeline small. To big documents slows down translation. Caching/Pooling: ^^^^^^^^^^^^^^^^ - Fine-tune the cocoon settings for the store and the other stuff. - Important is the size of the documents that will be cached, because caching appears to be very time consuming process. - If you are using the Caching Pipeline, you should be able to experience better performance each time you request it. However, if your cache is set too small to keep the entire XML in memory, the cache will be of no benefit. - Watch the cachability in logs, and make sure things are being fed from the cache. Only use dynamic data when it is needed. When pages are dynamic, they can't be cached 100%. XSP: ^^^^ - Consider turning your XSPs into generators by hand and call them directly. Don't need to do this for all pages, but only for those who are heavy loaded. XSLT: ^^^^^ - Try to keep the number of templates in the XSL translation small. - There are several ways of doing the same stuff in XSLT, test the difference between them. - Consider browser-dependent targetting to perform client-side XSLT. Cocoon is *very* fast if it doesn't do transformations. IE 5.5 and 6 are pretty compliant and might be something around 30% of your hits (probably more on some popular public web sites like Nasa's). Reducing one/third of the transformations might speed up a *LOT*. - How complicated are the XSLT stylesheets? If you are not using global variables or parameters, that speeds things up. JVM/OS: ^^^^^^^ - Consider using a good JVM on a good OS. Scalability is a very different beast than pure speed. An Apple DualG4 866 seems to run faster than a Sun Enterprise 4500 (and costs a fraction), but try hitting them with 2000 concurrent cocoon requests. - Fine-tune your JVM settings (max heap-size, initial memory). - Don't specify the -Xms parameter. - Set the -Xnoclassgc parameter on the Sun JDK 1.3.1! It reduces the frequency of need for garbage collection by permitting the memory allocated to unused classes to be reused (instead of having to be collected and/or compacted). Less fragmentation means less collection means better response times.
---------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
