Ron Blaschke wrote: > Ron Blaschke wrote: > > > > I've started to look at things, and were able to look at the Cocoon > > profiler things with "forrest run" in site-author/. > > Here's a short, edited, sample: > > body-index.html > > 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 > > [1] cocoon:/index.xml > [2] cocoon:/linkmap-index.html > [3] resources/stylesheets/declare-broken-site-links.xsl > [4] .../skins/pelt/xslt/html/document2html.xsl > [5].../skins/common/xslt/html/strip_namespaces.xsl
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. 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). Sorry, i don't don't know what to do now. -David
