> -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Hildebrandt, Ole > Gesendet: Freitag, 21. Mai 2004 17:02 > An: [EMAIL PROTECTED] > Betreff: AW: Performance Problems > > > Hi Marco, >
hi ole, > 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 yes, the pipelines themselves (which you reference via cocoon:/whatever) are cached, but not the 'references' (a bit fuzzy, I know ;-). that's what I meant with 'not really cached'. I'll just be a bit more specific: when the aggregation pipeline is setup, the aggregator resolves its parts' sources. this leads to the creation of SitemapSource objects, that represent cocoon:/ sources. that creation includes the whole setup process of the referenced pipelines. so if the referenced pipeline would in turn reference other cocoon:/ sources, the situation would be even worse. another issue is that SitemapSource forgets all the info collected after each access to the content it represents. now you see why the performance is so bad when doing many simultaneous requests: all that stuff is done over and over again for each request to the aggregation. that's what I actually meant ;-) when talking about suboptimal cacheability. > cache. THe aggregation-pipeline is not cached anyway. What do you mean by yeah, overlooked that noncaching ;-) > hacking the sitemap source? I meant using your own modified/enhanced version of SitemapSource. > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
