Re: [Bodington-developers] Resources and SoftCache

[Jon M. <jo...@te...>]

Matthew Buckett wrote:

>I'm looking at building a container (eg floor, building) that can easily
>contain 1000s of children. 
>
Aha! The recycling building!

>In the current implementation when a resource
>is visited (eg /admin/ground/sys) the code does this:
>
>First the root resource gets loaded.
>Then all the primary keys (PK) of the children are loaded.
>Then each child PK is used to load the full resource.
>If the name of the child resource matches the first part of the path
>(admin) then switch to using this resource and load all the children PKs.
>Continue doing this until the patch stops matching resources or we run
>out of path.
>  
>
It works well if you navigate through the site since at each level all 
the children need to be loaded in order to list them in the resource 
menu at each level. It also has the side affect of refreshing accesses 
to items in the cache that other users most frequently access. So, for 
example buildings are most frequently 'touched' in the cache and will be 
available.

>The problem is that you may well have to load all the child resources
>just to find the one you are looking for. This probably isn't as bad as
>it sounds at first as it is likely that the user will have navigated
>through the resource tree loading them all anyway.
>
>I decided to try to switch to using SoftCache and an additional IndexKey
>on Resource (parent_resource_id, name) so that I could do direct lookups
>and avoid having to enumerate through all the children.
>
>The problem is that the performance from IndexKey lookups from softcache
>seems to be very poor, of several orders of magnitude worse that
>PrimaryKey lookups. I realise that IndexKey has more complex hashCode()
>and equals() implementations that PrimaryKey() and SoftCache has to
>lookup stuff in several more hashes but I didn't expect things to be
>this bad. Is this a known problem?
>  
>
It's not a known problem to me. What is the 'where' clause that your 
IndexKey produces?

>I'm probably going to take a profiler to it so I can get some proper
>numbers and ideas about where exactly the problem lies but was wondering
>if anyone else has any ideas.
>
>  
>
First thing would be to see if the delay is in the Java execution or the 
database query. You could just try the various queries in the pgadmin 
query tool and look at execution time and the execution plan.

Jon