You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2002/12/09 09:40:27 UTC
Re: Cocoon performance tuning
Miles Elam wrote:
> Lenya L. Khachaturov wrote:
>
>> Are there any hints on making Cocoon perform better? I've been using
>> Cocoon for a couple of weeks and I can't call it "blazing fast" :-) As I
>> understood, it's performance greatly depends on the Java compiler and the
>> XSLT processor used. Which compiler and processor would you recommend? As
>> far as I know, Cocoon 2.0.3 uses Pizza and Xalan. Is Jikes and Saxon (or,
>> maybe, XSLTC) a better choice? I also use Resin 2.1.6 and Sun JDK
>> 1.4.0_01
>> - any recommendations here?
>>
> http://xml.apache.org/cocoon/performancetips.html
>
> Big point is setting log thresholds to ERROR (instead of INFO or DEBUG).
> This should give an immediate and dramatic performance gain.
How about setting these to ERROR by default?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon performance tuning
Posted by Steven Noels <st...@outerthought.org>.
Konstantin Piroumian wrote:
> It was just a proposal, you'll need to implement that somehow ;-)
> Hint: you can implement it in CocoonServlet to allow -D options to override
> default settings, such as cocoon.xconf, logkit.xconf locations, etc.
> Usability hint: Weblogic have simple RUNMODE (or so) parameter in the
> startup script and depending on it, it loads the needed configuration.
Jira does all this (not for performance, for db-config stuff) using Ant,
and HTTPD provides a high-performance httpd.conf example. Maybe we can
include some alternate configs inside the .war and add a
README-performance.txt
Still, I think DEBUG is too low-level of a loglevel to be configured by
default. So maybe we should switch things around and provide a
README-debug.txt instead :)
> Another hint: you'll need to setup separate *.xconf configurations at least
> for cocoon.xconf - to tune the perfomance and cache, and a logkit.xconf -
> for debug levels. Probably, it can be done only by changing the web.xml (and
> there you'll also will need to set the log level).
Thanks!
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon performance tuning
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Steven Noels" <st...@outerthought.org>
> Konstantin Piroumian wrote:
>
> > What about predefined configuration modes: development and production?
This
> > can be done using two separate config file sets and be switched using
a -D
> > startup option or an application init parameter.
>
> Beats me ATM - if you can provide me with some more hints, I could do it
> that way for 2.1/HEAD.
It was just a proposal, you'll need to implement that somehow ;-)
Hint: you can implement it in CocoonServlet to allow -D options to override
default settings, such as cocoon.xconf, logkit.xconf locations, etc.
Usability hint: Weblogic have simple RUNMODE (or so) parameter in the
startup script and depending on it, it loads the needed configuration.
Another hint: you'll need to setup separate *.xconf configurations at least
for cocoon.xconf - to tune the perfomance and cache, and a logkit.xconf -
for debug levels. Probably, it can be done only by changing the web.xml (and
there you'll also will need to set the log level).
>
> I will hardcode it in the 2.0.4 branch, however - maybe we can do a
> silent re-release then?
+0
Konstantin
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://radio.weblogs.com/0103539/
> stevenn at outerthought.org stevenn at apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon performance tuning
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Steven Noels wrote:
> Carsten Ziegeler wrote:
>
> > As long as I do the releases, I will not do a silent re-release.
> > That's for sure.
>
> Never mind, it was just a stupid idea - I'm crawling back to my cave.
>
My statement was not targetted directly at you, Steven. I just wanted
to make sure that silent re-releases will not happen.
And it seems that you have a quite comfortable cave anyway :)
Regards
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon performance tuning
Posted by Steven Noels <st...@outerthought.org>.
Carsten Ziegeler wrote:
> As long as I do the releases, I will not do a silent re-release.
> That's for sure.
Never mind, it was just a stupid idea - I'm crawling back to my cave.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon performance tuning
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Steven Noels wrote:
>
> > I will hardcode it in the 2.0.4 branch, however - maybe we can do a
> > silent re-release then?
>
> big -1 to silent re-releases.
>
> releases *are* by definition immutable. The use of MD5 and SIG to
> check-out intrusion and trojianing would be screwed up by silent
> re-releases and perceived as security attacks.
>
As long as I do the releases, I will not do a silent re-release.
That's for sure.
Apart from the security points, Stefano mentions, think about all
the mirrors, CDs etc. containing a Cocoon release. You will totally
confuse people if there are two versions of any release.
And doing a 2.0.5 is not much more work than a re-release.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon performance tuning
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
> I will hardcode it in the 2.0.4 branch, however - maybe we can do a
> silent re-release then?
big -1 to silent re-releases.
releases *are* by definition immutable. The use of MD5 and SIG to
check-out intrusion and trojianing would be screwed up by silent
re-releases and perceived as security attacks.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon performance tuning
Posted by Stuart Roebuck <st...@adolos.co.uk>.
On Tuesday, December 10, 2002, at 11:32 am, Steven Noels wrote:
> Konstantin Piroumian wrote:
>
>> What about predefined configuration modes: development and
>> production? This
>> can be done using two separate config file sets and be switched using
>> a -D
>> startup option or an application init parameter.
>
> Beats me ATM - if you can provide me with some more hints, I could do
> it that way for 2.1/HEAD.
>
> I will hardcode it in the 2.0.4 branch, however - maybe we can do a
> silent re-release then?
I have moved over to using 2.0.4 and have hit a number of issues with
the release. If there is a (relatively) 'silent' re-release then I
think there are a number of performance related issues that would be
worth including. Particularly given that that this fundamentally *the*
Cocoon release at the moment.
I'm still checking things a little before I raise the issues, but so
far my two points are:
1. Bug ID 12915 and the work-around in 2.0.4 mean that static image
files are not cached by browsers, leading to significant performance
issues compared with 2.0.3. see:
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12915>
2. In 2.0.3 (or thereabouts!) we used to get lots of ERROR level errors
with broken pipes when users disconnected before fully receiving a
response. This was a problem in itself. In 2.0.4 these same errors
appears to be labelled FATAL. I need to do some further checking here
to make sure this isn't a failure of our own code, but initial
examination would indicate that it isn't.
Stuart.
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck
(Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD
65AF
------------------------------------------------------------------------
-
Stuart Roebuck
stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS
<http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon performance tuning
Posted by Steven Noels <st...@outerthought.org>.
Konstantin Piroumian wrote:
> What about predefined configuration modes: development and production? This
> can be done using two separate config file sets and be switched using a -D
> startup option or an application init parameter.
Beats me ATM - if you can provide me with some more hints, I could do it
that way for 2.1/HEAD.
I will hardcode it in the 2.0.4 branch, however - maybe we can do a
silent re-release then?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon performance tuning
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Stefano Mazzocchi" <st...@apache.org>
> Steven Noels wrote:
>
> >> Big point is setting log thresholds to ERROR (instead of INFO or
> >> DEBUG). This should give an immediate and dramatic performance gain.
> >
> >
> > How about setting these to ERROR by default?
>
> Yeah, on Cocoon 2.0.x we should try to make an effort to make a fast
> cocoon ready right out of the box, people can turn on debugging if they
> want to.
>
> What do you think?
What about predefined configuration modes: development and production? This
can be done using two separate config file sets and be switched using a -D
startup option or an application init parameter.
Konstantin
>
> --
> Stefano Mazzocchi <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon performance tuning
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
I agree since developers always will read more info about how to "get
started development with Cocoon". Then there can be a document that will
explain how to turn on the developer stuff.
Antonio Gallardo.
Stefano Mazzocchi dijo:
> Steven Noels wrote:
>
>>> Big point is setting log thresholds to ERROR (instead of INFO or
>>> DEBUG). This should give an immediate and dramatic performance gain.
>>
>>
>> How about setting these to ERROR by default?
>
> Yeah, on Cocoon 2.0.x we should try to make an effort to make a fast
> cocoon ready right out of the box, people can turn on debugging if they
> want to.
>
> What do you think?
>
> --
> Stefano Mazzocchi <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon performance tuning
Posted by Geoff Howard <ge...@leverageweb.com>.
-----Original Message-----
From: Tony Collen [mailto:tc@hist.umn.edu]
Sent: Monday, December 09, 2002 8:17 PM
To: cocoon-dev@xml.apache.org
Subject: Re: Cocoon performance tuning
On Mon, 9 Dec 2002, Stefano Mazzocchi wrote:
> Steven Noels wrote:
>
> >> Big point is setting log thresholds to ERROR (instead of INFO or
> >> DEBUG). This should give an immediate and dramatic performance gain.
> >
> >
> > How about setting these to ERROR by default?
>
> Yeah, on Cocoon 2.0.x we should try to make an effort to make a fast
> cocoon ready right out of the box, people can turn on debugging if they
> want to.
>
> What do you think?
+1, I don't see why the logging needs to be so verbose on releases.
Tony
Tony Collen -- tc@socsci.umn.edu
College of Liberal Arts University of Minnesota, Minneapolis, West Bank
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon performance tuning
Posted by Tony Collen <tc...@hist.umn.edu>.
On Mon, 9 Dec 2002, Stefano Mazzocchi wrote:
> Steven Noels wrote:
>
> >> Big point is setting log thresholds to ERROR (instead of INFO or
> >> DEBUG). This should give an immediate and dramatic performance gain.
> >
> >
> > How about setting these to ERROR by default?
>
> Yeah, on Cocoon 2.0.x we should try to make an effort to make a fast
> cocoon ready right out of the box, people can turn on debugging if they
> want to.
>
> What do you think?
+1, I don't see why the logging needs to be so verbose on releases.
Tony
Tony Collen -- tc@socsci.umn.edu
College of Liberal Arts University of Minnesota, Minneapolis, West Bank
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon performance tuning
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
>> Big point is setting log thresholds to ERROR (instead of INFO or
>> DEBUG). This should give an immediate and dramatic performance gain.
>
>
> How about setting these to ERROR by default?
Yeah, on Cocoon 2.0.x we should try to make an effort to make a fast
cocoon ready right out of the box, people can turn on debugging if they
want to.
What do you think?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org