forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Locationmap Caching Help (FOR-732/711)
Date Thu, 30 Mar 2006 22:22:36 GMT
Tim Williams wrote:
> On 3/30/06, Ross Gardler <rgardler@apache.org> wrote:
> 
>>Tim Williams wrote:
>>
>>>On 3/30/06, Ross Gardler <rgardler@apache.org> wrote:
>>>
>>>
>>>>Tim Williams wrote:
>>>>
>>>>
>>>>>On 3/30/06, Ross Gardler <rgardler@apache.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Tim Williams wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On 3/30/06, Ross Gardler <rgardler@apache.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Tim Williams wrote:
>>>>
>>>>...
>>>>
>>>>
>>>>
>>>>>I think I'm not explaining it well enough.  "n" (e.g. 315) is not the
>>>>>number of nodes (SelectNode, MountNode, etc.); "n" is the number of
>>>>>references to "lm:some-resource" involved in a given request.  In
>>>>>other words, traversing all of the nodes is actually really fast,
>>>>>traversing all of the nodes for each of the 315 references to an
>>>>>lm:some-resource is, in total, slow.
>>>>
>>>>Ahhh... OK, that makes more sense now - sorry for being so thick.
>>>>
>>>>I'm still having real difficulty understanding why a single page results
>>>>in 315 "lm:some-resource" requests. Do we have any idea waht these are?
>>>>I ask because it appears that in your testing you have set up some
>>>>decent profiling.
>>>
>>>
>>>Well, I haven't been looking at *what* they are really.  No decent
>>>profiling - just basic logging.  We're a victim of our own success I
>>>reckon - we've moved tons of stuff to use the locationmap protocol and
>>>now we're seeing the fruits of it.
>>>
>>>My linux command skills leave something to be desired but...
>>>cd $FORREST_HOME/main
>>>grep lm: * | more
>>>
>>>and
>>>
>>>cd $FORREST_HOME/main
>>>grep lm: * | awk 'END {print NR}'
>>>
>>>This returns 223 - which, i think, is the number of references to the
>>>locationmap protocol in our core xmaps.  I reckon some are referenced
>>>multiple times?
>>
>>I just can't believe that we *need& 315 lm:requests for a single page. I
>>would expect something like:
>>
>>- around 10 stylesheets (depends on input format)
>>- around of 25 images (depends on skin/theme)
>>- 2 or 3 CSS files
>>- possibly a javascript file or two
>>
>>Most of these should be cached by the Cocoon sitemap so only requested
>>once, but, Cocoon needs to resolve the lm: protocol in order to check
>>validity.
>>
>>Then there will be the requests for the content which should be 1 source
>>file and x image files.
>>
>>So that (back of the envelope) estimate would see something like 40-50
>>lm: requests for most pages.
>>
>>How this gets to 315 is a worry, and needs some investigation.
> 
> 
> You're very right.
> 
> 
>>Are your figures using skins or the dispatcher? If it's easy to do
>>perhaps you can give a comparison of the numbers with the alternative
>>(I'd be very suprised if the Dispatcer is lower, but I'd like to see the
>>amount of difference).
> 
> 
> skins; dispatcher turns up ~172 lm: references.

WooHoo!!! Dispatcher team - congratulations on being considerably more 
efficient.

It's still too high, but quite an improvement.

> One of the big culprits that i see is doing Cocoon-selectors vs
> Locationmap selectors.  Whenever we do lm: references in Cocoon
> selectors, we're duplicating input module requests - one to test for
> not null, then the other to pull the actual value.
> 
> For example, this snippet causes duplicate lm requests:
>            <map:select type="exists">
>              <map:when test="{lm:project-skinconf.xsl}">
>                <map:transform src="{lm:project-skinconf.xsl}"/>
>              </map:when>
> 
> I fear this is the tip of the iceberg... when I find time, I'll
> continue to pursue this line of investigation, just wanted to send a
> note that you're direction was correct.

Glad I could help a little - it's amazing how just throwing out ideas 
can help sometimes (but can also end up as red herrings). I doubt I'm 
going to get time to look into this in detail anytime soon, but if you 
want to bounce things around again - you know where I am ;-)

Ross

Mime
View raw message