Performance Problems

["Hildebrandt, Ole" <ol...@eds.com>]

Hi,

I have the following aggregation pipeline: 

		<map:pipeline type="profile-noncaching">
			<map:match pattern="testpage">
				<map:act type="dispatchaction">
					<map:aggregate
element="portalseite">
						<map:part
src="cocoon:/topnav?{topnav}" element="topnav"/>
						<map:part
src="cocoon:/leftnav?{leftnav}" />
						<map:part
src="cocoon:/content?{content}" element="content"/>
					</map:aggregate>
					<map:transform
src="xslt/{pagelayout}"/> 
					<map:serialize type="html"/>
				</map:act>
			</map:match>

The "dispatchaction" provides some parameters for the aggregation parts and
provides the name of the XSLT-Template for the pagelayout. All the parts are
generated in a separate caching pipeline. 

I did a stress test with JMeter and fired 20 simultanous requests. The
performance result are not very good. 

Average response time is 1800 ms. 
When I fire a single request I get quite good response time of 30-40 ms.

The profiling-page tells me the following:

<aggregator> Total: 1680 Setup: 1538 Processing: 142 
xslt src=xslt/pagelayout_1.xsl Total: 3 Setup: 2 Processing: 1 
Html-serializing Total:1 Setup:0 Processing:1
So setting up the aggregation takes most of the time. Can anyone give me a
hint about what to do to decrease this setup-time? Does the setup-time
include the processing-time of the parts?
Thanks for any suggestions
Kind regards
Ole




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

AW: Performance Problems

[Marco Rolappe <m_...@web.de>]

hi ole,

see below

> -----Ursprüngliche Nachricht-----
> Von: users-return-67891-m_rolappe=web.de@cocoon.apache.org
> [mailto:users-return-67891-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Hildebrandt, Ole
> Gesendet: Freitag, 21. Mai 2004 16:19
> An: users@cocoon.apache.org
> Betreff: Performance Problems
>
>
> Hi,
>
> I have the following aggregation pipeline:
>
> 		<map:pipeline type="profile-noncaching">
> 			<map:match pattern="testpage">
> 				<map:act type="dispatchaction">
> 					<map:aggregate
> element="portalseite">
> 						<map:part
> src="cocoon:/topnav?{topnav}" element="topnav"/>
> 						<map:part
> src="cocoon:/leftnav?{leftnav}" />
> 						<map:part
> src="cocoon:/content?{content}" element="content"/>
> 					</map:aggregate>
> 					<map:transform
> src="xslt/{pagelayout}"/>
> 					<map:serialize type="html"/>
> 				</map:act>
> 			</map:match>
>
> The "dispatchaction" provides some parameters for the aggregation
> parts and
> provides the name of the XSLT-Template for the pagelayout. All
> the parts are
> generated in a separate caching pipeline.

though your referenced parts may come from caching pipelines, that currently
doesn't improve performance; proper cacheability of SitemapSource's
(cocoon:/ stuff) hasn't yet been implemented.

> I did a stress test with JMeter and fired 20 simultanous requests. The
> performance result are not very good.
>
> Average response time is 1800 ms.
> When I fire a single request I get quite good response time of 30-40 ms.

that's because the single parts are 'not really' cached and thus the
aggregation isn't. that means your 20 simultaneous requests will more or
less trigger 20 aggregations.

>
> The profiling-page tells me the following:
>
> <aggregator> Total: 1680 Setup: 1538 Processing: 142
> xslt src=xslt/pagelayout_1.xsl Total: 3 Setup: 2 Processing: 1
> Html-serializing Total:1 Setup:0 Processing:1
> So setting up the aggregation takes most of the time. Can anyone give me a

the aggregation setup mainly consists of resolving the parts' sources. in
your case that means resolving (and creating) SitemapSource's. because of
the bad cacheability that leads to unnecesary recreating the SitemapSource's
over and over again.

> hint about what to do to decrease this setup-time? Does the setup-time

my hint is: hack your SitemapSource ;-) I had posted a patch back then which
implements that cacheability and am using it myself (my app heavily uses
cocoon:/ sources).

the problem with the standard SitemapSource mainly is that it doesn't return
a last modification timestamp (even if it could) and doesn't properly handle
the SourceValidity (telling the pipeline about whether the respective cache
entry is still valid).

> include the processing-time of the parts?

no.

> Thanks for any suggestions
> Kind regards
> Ole
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org