Ron Blaschke wrote: > David Crossley wrote: > > David Crossley wrote: > >> Ron Blaschke wrote: > >> > Ron Blaschke wrote: > > [snip] > >> > NN Components(Role) Average time Lastest times > >> > 1 file ([1]) 213 ms 30 ms 30 ms 581 ms > >> > 2 idgen 6 ms 10 ms 0 ms 10 ms > >> > 3 xinclude 4202 ms 6219 ms 6389 ms 0 ms > >> > 4 linkrewriter ([2]) 2333 ms 0 ms 10 ms 6990 ms > >> > 5 xslt ([3]) 13 ms 20 ms 20 ms 0 ms > >> > 6 xslt ([4]) 66 ms 20 ms 10 ms 170 ms > >> > 7 xslt ([5]) 6 ms 0 ms 10 ms 10 ms > >> > 8 html 0 ms 0 ms 0 ms 0 ms > >> > Total time 6269 ms 6269 ms 6429 ms 7311 ms > [snip] > > >> Let us interpret that. The body-index.html was requested > >> three times. The right-hand column is the initial request. > >> > >> Other columns are the subsequent requests. These should all > >> come from the cache, and that is true for most components. > >> > >> However, "xinclude" does not. Its first processing is fast > >> (there are no xinclude statements in the source). On every > >> subsequent occasion it is being processed and taking too > >> much time. > > Right. > > >> Comment-out that xinclude transformer in sitemap.xmap > >> and the "extra" time then gets listed on the "idgen". > >> Comment-out that and the time moves to "linkrewriter". > >> > >> I wondered if the stylesheet that does the profiler > >> presentation might have some bug. So i added the > >> prettier stylesheet that is provided in the Cocoon block. > >> Same effect. (The stylesheet seems better so i left that > >> in place). > > Quite interesting. There seems to be something odd going on > here. > > > Compared with revision 227321 ... > > This revision number is from Cocoon, right?
No, Forrest. This was just before the upgrade of Forrest's Cocoon. > > body-index.html > > NN Component Av. Other times > > 1 file 252 16 16 489 > > 2 idgen 3 1 1 5 > > 3 xinclude 9 7 7 11 > > 4 linkrewriter 1011 9 9 2014 > > 5 xslt 85 15 15 156 > > 6 xslt 115 13 13 218 > > 7 xslt 10 1 1 19 > > 8 html 11 0 0 22 > > 9 TOTAL 1567 88 64 3497 > > Nice job, David. These numbers look quite good. This should help > narrow the problem down. A comparison of two CPU profiles might bring > something up. > > Before digging down to the problem, I thought I'd start with the > profiler plugin, so don't wait for me looking for the problem. > > Second, I am investigating how to tell Forrest that index.html and > /index.html really are the same thing. That would certainly help. These issues might be related: http://issues.apache.org/jira/browse/FOR-268 "relative URIs with absolute paths are broken in the site.xml linking mechanism" http://issues.apache.org/jira/browse/FOR-271 "extra leading slash when absolute path URIs used in site.xml" webapp/resources/stylesheets/absolutize-linkmap.xsl webapp/resources/stylesheets/dotdots.xsl -David
