You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by fr...@apache.org on 2002/03/28 23:33:40 UTC
cvs commit: xml-cocoon2/src/documentation/xdocs performancetips.xml book.xml
froehlich 02/03/28 14:33:40
Modified: src/documentation/xdocs book.xml
Added: src/documentation/xdocs performancetips.xml
Log:
added performance tips in xdoc style as a top level document
Revision Changes Path
1.8 +2 -1 xml-cocoon2/src/documentation/xdocs/book.xml
Index: book.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/book.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- book.xml 27 Feb 2002 14:44:05 -0000 1.7
+++ book.xml 28 Mar 2002 22:33:40 -0000 1.8
@@ -3,7 +3,7 @@
<book software="Apache Cocoon"
title="Apache Cocoon Documentation"
- copyright="@year@ The Apache Software Foundation"
+ copyright="1999-2002 The Apache Software Foundation"
xmlns:xlink="http://www.w3.org/1999/xlink">
<menu label="About">
@@ -19,6 +19,7 @@
<menu-item label="Dev Guide" href="developing/index.html"/>
<menu-item label="Tutorial" href="tutorial.html"/>
<menu-item label="FAQs" href="faq.html"/>
+ <menu-item label="Performance" href="performancetips.html"/>
<menu-item label="ToC" href="doclist.html"/>
</menu>
1.1 xml-cocoon2/src/documentation/xdocs/performancetips.xml
Index: performancetips.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "dtd/document-v10.dtd">
<document>
<header>
<title>Apache Cocoon Performance Tips</title>
<authors>
<person name="Gerhard Froehlich" email="g-froehlich@gmx.de"/>
</authors>
</header>
<body>
<s1 title="Disclaimer">
<p>The Cocoon Performance Tips in this version is a loose collection of
usesnet articles regarding how to improve the Apache Cocoon performance.</p>
<p>As in the real world, it needs some kind of evolution to get better.
If you have suggestions how to make it better or new kool tips, then be brave and
send it to the <link href="http://xml.apache.org/cocoon/mail-lists.html">
Cocoon Mailing Lists</link>!
<note>Sometimes the tips maybe doubled or contradictory. If you notice something
like that, then send a note to the <link href="http://xml.apache.org/cocoon/mail-lists.html">
Cocoon Mailing Lists</link></note>.
</p>
</s1>
<s1 title="Common">
<ul>
<li>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.</li>
<li>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).</li>
<li>Consider prerendering or time-based batch-process the static parts
of your site. PDF reports, rasterized SVG graphs or things that change
regularly.</li>
<li>For optimum performance with Tomcat 4 and Cocoon 2,
use the HTTP/1.0 connector.</li>
<li>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 Cocoon app would be a bit much when Tomcat + our Cocoon
app is doing fine.</li>
<li>Disable resource reloading. The disk I/O system could become the
bottleneck.</li>
<li>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.</li>
</ul>
</s1>
<s1 title="Caching and Pooling">
<ul>
<li>Fine-tune the pool sizes for components in the files cocoon.xconf and
sitemap.xmap. If the pools are too small for the load this will have a great
impact on your performance. The goal is to achieve such a 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 set the maximum pool size to 200 xslt
transformers. They will be created when needed and retained to the pool
for future use.
</li>
<li>Fine-tune the cocoon settings for the store and the other stuff.</li>
<li>Important is the size of the documents that will be cached, because
caching appears to be very time consuming process.</li>
<li>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.</li>
<li>Watch the cachability in the log files, and make sure that things are being fed from the
cache. <note>Only use dynamic data when it is needed. Dynamic pages can't be cached 100%.
</note></li>
</ul>
</s1>
<s1 title="JVM and OS">
<ul>
<li>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.</li>
<li>Fine-tune your JVM settings (max heap-size, initial memory).</li>
<li>Don't specify the -Xms parameter.</li>
<li>Set the <code>-Xnoclassgc</code> 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.</li>
</ul>
</s1>
<s1 title="Perfomance Formulas">
<ul>
<li>Consider following formula for Pipeline Processing:
<p><code>Number_of_simultaneous_users * depth_of_content_aggregation</code></p>
</li>
<li>Consider following formula for Generators/Transformers/Serializers:
<p><code>Amount_required_to_process_one_request * Number_of_simultaneous_users</code></p>
</li>
<li>Consider following formula for Connectors:
<p><code>Count_of_pipeline_components_to_process_one_request *
Number_of_simultaneous_users</code></p></li>
</ul>
</s1>
<s1 title="Pipelines">
<ul>
<li>Keep an eye on the overall complexity of pipelines.</li>
<li>Try to keep the size of the documents going through the pipeline
small. To big documents slows down translation.</li>
</ul>
</s1>
<s1 title="XSP">
<ul>
<li>Consider turning your XSPs into Generators by hand and call them
directly. Of course you don't need to do this for all pages, but it's
recommended to it for those which are heavy loaded.</li>
</ul>
</s1>
<s1 title="XSLT and XSL">
<note>For more tips and information about XSL and XSLT grep the Internet and the
<link href="http://xml.apache.org/xalan-j/index.html">Xalan Homepage</link>
</note>
<ul>
<li>Try to keep the number of templates in the XSL translation small.</li>
<li>There are several ways of doing the same stuff in XSLT, test the
difference between them.</li>
<li>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.</li>
<li>How complicated are the XSLT stylesheets? If you are not using global
variables or parameters this will speeds things up.</li>
</ul>
</s1>
</body>
</document>
----------------------------------------------------------------------
In case of troubles, e-mail: webmaster@xml.apache.org
To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org