RE: Cocoon performance tuning

[Carsten Ziegeler]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Steven Noels]

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 Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0103539/
stevenn at outerthought.orgstevenn at apache.org


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Cocoon performance tuning

[Carsten Ziegeler]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Cocoon performance tuning

[Stephen Ng]

> 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:
>   

I agree--this is a serious problem which would keep me from migrating to
2.0.4

Stephen Ng
Lumigent

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Stefano Mazzocchi]

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   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Stuart Roebuck]

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:
	

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   
[EMAIL PROTECTED]
Systems Architect Java, XML, MacOS X, XP,  
etc.
ADOLOS



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Steven Noels]

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 Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0103539/
stevenn at outerthought.orgstevenn at apache.org


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Konstantin Piroumian]

From: "Steven Noels" <[EMAIL PROTECTED]>
> 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 Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at  http://radio.weblogs.com/0103539/
> stevenn at outerthought.orgstevenn at apache.org
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Steven Noels]

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 Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0103539/
stevenn at outerthought.orgstevenn at apache.org


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Cocoon performance tuning

[Geoff Howard]

-Original Message-
From: Tony Collen [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 09, 2002 8:17 PM
To: [EMAIL PROTECTED]
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 -- [EMAIL PROTECTED]
College of Liberal Arts   University of Minnesota, Minneapolis, West Bank


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Konstantin Piroumian]

From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
> 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   <[EMAIL PROTECTED]>
> 
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Tony Collen]

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 -- [EMAIL PROTECTED]
College of Liberal Arts   University of Minnesota, Minneapolis, West Bank


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Antonio Gallardo]

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   <[EMAIL PROTECTED]>
> 
>
>
>
> - To
> unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Stefano Mazzocchi]

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   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Cocoon performance tuning

[Steven Noels]

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 Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0103539/
stevenn at outerthought.orgstevenn at apache.org


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]