Hi Marco, Thanks for your reply. I included the generation-time in the result so from that I can tell that the three parts are not re-generated but taken from the cache. THe aggregation-pipeline is not cached anyway. What do you mean by hacking the sitemap source?
Kind regards Ole > -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 21. Mai 2004 16:48 > An: [EMAIL PROTECTED] > Betreff: AW: Performance Problems > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
