hi ole, see below
> -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Hildebrandt, Ole > Gesendet: Freitag, 21. Mai 2004 16:19 > An: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
