[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