Well – there is a performance issue in the portal code in Sakai 2.5. There are more queries to the SAKAI_SITE_PROPERTY in Sakai 2.5 than in 2.4.
In looking at things there were several instances of “too many queries” – not just from 2.5 – but for a few features that were added to portal between 2.3 and 2.5.
So I pored over the code for the last three days and figured out what kind of optimization which had already been done – and figure out where bits were leaking through the prior optimization.
I talked to Aaron and Ian – and came up with two solutions – one using memcache for the properties and another using thread local.
I think that this will be important for Sakai 2.5 sites – My guess is that in the summer many are not noticing the additional query load on the main portal displays. Without these patches things will likely slow down a bit and/or consumer more resources.
I initially made a property to control which tables the properties get cached in memory – my guess is that particularly for 64-bit JVM’s this should be
DbFlatPropertiesCache=:all:
But at a minimum this is needed:
DbFlatPropertiesCache=:SAKAI_SITE_PROPERTY:
After some testing and experience we should figure out which of these two should be the default. I think that the methodology (suggested by Ian) is to look at query patterns and see if you are seeing too many hits on tables like:
SAKAI_SITE_PAGE_PROPERTY, SAKAI_SITE_TOOL_PROPERTY, SAKAI_SITE_GROUP_PROPERTY, …
Then simply add them to the list in preferences – and see if things get better.
This is a nice, clean, short-lived memcache – and it is automated perfectly when properties are changed on the same server (i.e. when an instructor makes a change and presses refresh – the display will be perfect – instantly reflecting the changes).
The Thread Local code is obvious and must be done. It simply makes sure that the portal only gets the list of visitable sites once from the database.
Both of these mods are really simple and clean and should be trivial to review.
I currently have some print statements that can be uncommented if folks want to watch the new caches in action.
Once some testing happens – I will remove these before sending it to trunk.
Now this is done, I can start working on my talk for tomorrow about functionality mashup.
Here is my message to the dev list about it.