Geoff,
Thanks for the help! I see about a second and a half
performance boost (10.29s to 8.87s) on startup. The
longest to respond is a sitemap with various XSP's and
a fop2pdf generator (12.35 sec). I have two more
issue though in light of your tips:
Very glad to hear it - I'd think you'll be able to get that down quite a bit more. See more comments below.
<questions> 1) Should I "declare" the components only in the sitemap that uses them or is the performance the same when they are "declared" in the base sitemap (not "declared" in sub-sitemap)?
I don't know if sitemap components are loaded lazily or not in the tree processor (2.1), but it would be an easy experiment. You may be able to find hints in the logs (if you turn logging up to debug).
That reminds me. Logging is by default turned to ERROR (WARN?) now in 2.1 which was not the case with earlier versions, or earlier in 2.1 cvs. But web.xml has an additional config for logging during startup. I think this may be left to debug by default, and you may want to experiment with startup times with it changed.
2) Are JSP/XSP sources compiled everytime the server is restarted? If so, will getting my hands on the class generated and "generating" it otherwise improve the performace? </questions>
They should not be recompiled on server restart (though I'm not sure about JSP within Cocoon if called from the JSP reader or generator). You need to make sure though that your servlet container is not deleting the work directory on startup or shutdown. ( I think I recently discovered that Jetty does this). If it is, they will be recompiled because the class file will be missing. You can fix this either by changing config on the servlet container or by changing Cocoon's work directory to one that isn't getting deleted. The same by the way goes with the cache directory.
Your idea to get the pregenerated class file will work - though I'm not sure if XSP engine uses the same class loader, or if it only looks in the configured work directory. This will change where you would need to put it to avoid recompiling.
Also, the build process has a step that is supposed to precompile XSPs. You may not want to rebuild the entire cocoon project each time you change an xsp but you could look into creating a new build target for yourself to do just this step. If you figure it out, please wiki it.
Regarding components: I am not sure which I use and which I do not. I use Cocoon for the basics and will have to do some reading.
Yes, this is an issue. It won't be clear even to experienced users what all those components are. It's better now that blocks are here, but not everything can be/is in a block. Maybe if you did an inventory of what you still have in cocoon.roles and cocoon.xconf and wiki'd it we could build up a little page detailing what each is and when you could get rid of it.
Geoff
Thanks a million, Julian
--- Geoff Howard <[EMAIL PROTECTED]> wrote:
Reinhard P�tz wrote:
-----Original Message-----
From: Julian [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 4:20 PM
To: cocoon
Subject: Confused About Perfomance Issues
Hi,
I have looked into this a few times, but am not "getting it".
<question> How can I configure/build Cocoon to pre-load/pre-compile sitemaps before or during
server
startup? </question>
In 2.1 (latest CVS) the interpreted sitemap is
used - no compilation is
necessary.
<scenario> Every time my server is restarted Cocoon takes
about
8-10 secs. to respond to requests to a given
sitemap.
I believe this is sitemap compilation. I have a
few
sitemaps so this causes some serious lag time,
albeit
on first request...afterwards all responds
quickly.
jre 1.4.1, Cocoon CVS version, Tomcat 4.1.12 </scenario>
It's not only the sitemap - Cocoon initialized
many components and this
needs some time at startup. It also takes some
time to compile XSP pages
(in the case you use them).
And this time can be reduced by eliminating all
unused components. First, start by building without unused blocks. Second, edit your sitemaps to remove any unused sitemap components
(e.g., Generators you'll never use). If things are still not
noticeably better, examine cocoon.xconf and cocoon.roles for components you
expect to never need. This last step is a little more advanced.
If there are any questions about what a component
is/does ask here or on the dev list.
Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
