[Mondrian] Optimizing FunUtil.evaluateMembers()

Eric McDermid mcdermid at stonecreek.com
Mon Jan 5 14:56:37 EST 2009


Marc and I have been looking at performance optimizations for a client  
using Mondrian 2.4 against MySQL.  Turns out that about 60% of the  
time their app spends in Mondrian code is in  
mondrian.olap.fun.FunUtil.evaluateMembers(), so we're trying to find  
ways to improve that hit.

As it turns out, a majority of the time spent in evaluateMembers() is  
actually spent at a lower level, in  
mondrian.rolap.RolapAggregationManager.getCellFromCache(), and that's  
on a secondary hit (i.e. it doesn't include SQL access time, since a  
previous execution already loaded the cache).  I don't see any  
immediately obvious bottlenecks to eliminate there, however.

Since evaluateMembers() cycles through a member iterator, one thought  
was to do those evaluations in parallel using multiple threads.  At  
first glance this seemed promising, but after digging a little deeper  
I'm concerned that this would require a major overhaul to ensure that  
all the calculators, functions in the function table, cache access,  
etcetera are all threadsafe.  Additionally, we'd likely need to ensure  
that the worker threads don't wind up running the same SQL queries  
downstream somewhere.

Has anyone else run into similar issues?  We are working on upgrading  
the app to the latest Mondrian release, but that will take a while,  
and I'm not familiar enough with the deltas between the two Mondrian  
versions to know if upgrading is likely to help with the problem we're  
seeing.

  -- Eric





More information about the Mondrian mailing list