machine spec for forrest run

[Kevin <fo...@kegcl.demon.co.uk>]

Does anyone have a performance problem using forrest run.
My test is on the main index page of seed-v2.

It is very slow for me over 2 minutes for the first
http://localhost:8888/index.html Over 1 minute to refresh
this page.

I use a 1.2G machine with 512M memory running Linux
Fedora Core 3. CPU hits 100% about half memory used
and no swapping. 

Any tips on speeding up forrest run I have tried commenting
out the debug statement in forrest.properties

Can I switch off all the debug on the console maybe that
will help?

Thanks,
Kevin

Re: machine spec for forrest run

[Thorsten Scherler <th...@apache.org>]

El jue, 03-11-2005 a las 12:25 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribió:
> > 
> >>Kevin wrote:
> >>
> >>>Does anyone have a performance problem using forrest run.
> >>>My test is on the main index page of seed-v2.
> >>
> >>I'm not using views 2, so cannot comment directly. However, it is known 
> >>that there are lots of performance issues with views 2. 
> > 
> > 
> > Why? If you have said v1 than you get a +1 from me because of the
> > extensive usage of xinclude which is not cacheable in v1. In v2 I do not
> > use xinclude at all (beside the default usage from main pipes of forrest
> > core).
> 
> OK, maybe I spoke too soon. But I do think there is much happening in 
> XSL that need not happen in a memory exhaustive approach. This is not a 
> criticism of your work, merely an observation of how it can be improved 
> with respect to performance.
> 

Agree

> >>The tentative 
> >>plan is to move much of the heavy XSL processing into Java components. 
> >>Most of the stuff that is done to bring the contracts together, for 
> >>example, need not be done with processor and memory intensive XSL 
> >>transforms.
> > 
> > 
> > Actually I debugged it a bit and what I see is that the locationmap
> > lookups are taking ages. Since v2 is totally based on the lm that may
> > have introduced some new performance issues.
> 
> Yeah, that too needs improving: http://issues.apache.org/jira/browse/FOR-711
> 
> > Sorry for not being faster in providing a transformer for overcome the
> > xsl aggregation but I am ATM a wee bit handicapped without an internet
> > connection and moving all v2 stuff to their final locations.
> 
> Come on Thorsten, you know there is no need to apologise. We don't 
> expect *you* to do it, I only raise it here so that everyone is aware of 
> things that need to be done and therefore how they can contribute.
> 

Actually I am sorry even if I do not have to. ;-) 

You are right in what you just pointed out and thanks for doing it. I
have a half baked transformer on my harddrive but then started to play
around with the theme switching stuff, run into the resource problematic
and the moving of resources. 

All this work that I started on the same time is holding up the people
to go on with their work (e.g. xhtml2). ...

> >>In other words, performance has not been addressed yet.
> > 
> > 
> > That is not true! Like stated above I ripped out the xinclude stuff that
> > was pointed out to be the worst part for performance.
> 
> Sorry, performance is being addressed, please help ;-)
> 

+1 

I started v2 to really address this performance issues but like Ross
stated: Please help.


> Ross

thx Ross

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: machine spec for forrest run

[Ross Gardler <rg...@apache.org>]

Thorsten Scherler wrote:
> El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribió:
> 
>>Kevin wrote:
>>
>>>Does anyone have a performance problem using forrest run.
>>>My test is on the main index page of seed-v2.
>>
>>I'm not using views 2, so cannot comment directly. However, it is known 
>>that there are lots of performance issues with views 2. 
> 
> 
> Why? If you have said v1 than you get a +1 from me because of the
> extensive usage of xinclude which is not cacheable in v1. In v2 I do not
> use xinclude at all (beside the default usage from main pipes of forrest
> core).

OK, maybe I spoke too soon. But I do think there is much happening in 
XSL that need not happen in a memory exhaustive approach. This is not a 
criticism of your work, merely an observation of how it can be improved 
with respect to performance.

>>The tentative 
>>plan is to move much of the heavy XSL processing into Java components. 
>>Most of the stuff that is done to bring the contracts together, for 
>>example, need not be done with processor and memory intensive XSL 
>>transforms.
> 
> 
> Actually I debugged it a bit and what I see is that the locationmap
> lookups are taking ages. Since v2 is totally based on the lm that may
> have introduced some new performance issues.

Yeah, that too needs improving: http://issues.apache.org/jira/browse/FOR-711

> Sorry for not being faster in providing a transformer for overcome the
> xsl aggregation but I am ATM a wee bit handicapped without an internet
> connection and moving all v2 stuff to their final locations.

Come on Thorsten, you know there is no need to apologise. We don't 
expect *you* to do it, I only raise it here so that everyone is aware of 
things that need to be done and therefore how they can contribute.

>>In other words, performance has not been addressed yet.
> 
> 
> That is not true! Like stated above I ripped out the xinclude stuff that
> was pointed out to be the worst part for performance.

Sorry, performance is being addressed, please help ;-)

Ross

Re: machine spec for forrest run

[Thorsten Scherler <th...@apache.org>]

El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribió:
> Kevin wrote:
> > Does anyone have a performance problem using forrest run.
> > My test is on the main index page of seed-v2.
> 
> I'm not using views 2, so cannot comment directly. However, it is known 
> that there are lots of performance issues with views 2. 

Why? If you have said v1 than you get a +1 from me because of the
extensive usage of xinclude which is not cacheable in v1. In v2 I do not
use xinclude at all (beside the default usage from main pipes of forrest
core).

> The tentative 
> plan is to move much of the heavy XSL processing into Java components. 
> Most of the stuff that is done to bring the contracts together, for 
> example, need not be done with processor and memory intensive XSL 
> transforms.

Actually I debugged it a bit and what I see is that the locationmap
lookups are taking ages. Since v2 is totally based on the lm that may
have introduced some new performance issues.

Sorry for not being faster in providing a transformer for overcome the
xsl aggregation but I am ATM a wee bit handicapped without an internet
connection and moving all v2 stuff to their final locations.

> In other words, performance has not been addressed yet.

That is not true! Like stated above I ripped out the xinclude stuff that
was pointed out to be the worst part for performance.

> Ross

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: machine spec for forrest run

[Ross Gardler <rg...@apache.org>]

Kevin wrote:
> Does anyone have a performance problem using forrest run.
> My test is on the main index page of seed-v2.

I'm not using views 2, so cannot comment directly. However, it is known 
that there are lots of performance issues with views 2. The tentative 
plan is to move much of the heavy XSL processing into Java components. 
Most of the stuff that is done to bring the contracts together, for 
example, need not be done with processor and memory intensive XSL 
transforms.

In other words, performance has not been addressed yet.

Ross