[Mondrian] XMLA response size

Julian Hyde jhyde at pentaho.com
Fri Aug 7 14:23:42 EDT 2009


 Matt Campbell wrote:
I think compression is a great idea, but it won't really help in our case,
since we have no control over the XMLA client (Cognos).  It'll actually be
the rare case where you could influence the HTTP request of a 3rd party

And even if we could compress the response for Cognos, we would still have a
performance issue.  From what we've seen the bulk of the time is spent
processing the large response.  Network overhead is a fraction of that
(we're running over a gigabit network--network time for these responses is

My comments about CPU benefit were aluding to that. A verbose protocol can
have impact in CPU & bus utilization as well as network throughput &
response time. The response would become large at some part of the pipeline,
but there would still be savings in the network stack.
But anyway. It's clear that this won't work for you.

Given that, I'd still like to see a way to trim down the response. From a
scan of the spec I don't see anything that says that some content is

My reading of the spec is that if a provider does not return, say, OlapInfo,
then it is not in compliance with the spec. There's no way in the spec for a
client to say it DOES NOT want OlapInfo, and therefore the server has to
provide it. So, the content is mandatory.
The spec allows some control over what comes back, using the
Content=(None|Schema|Data|SchemaData) attribute. Page 51 of
http://www.xmla.org/xmla1.1.doc. We implement that of the spec.
I propose that we allow alternative values for that attribute, say
Content=DataWithoutInfo. (Or suggest a better term.) This would be an
extension to the spec, and probably you would be the only client using it,
but I would allow it because it wouldn't require a lot of code changes to
the server.
I looked over the olap4j driver (XmlaOlap4jCellSet.java) and it looks like
it does need the OlapInfo element. So, the olap4j driver would need to use a
compression approach, not your approach of omitting elements. Luc, let's
discuss this in another thread.
By the way, I came across Microsoft's patent. Obviously we do NOT want to
implement this in Mondrian!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20090807/53dafa63/attachment.html 

More information about the Mondrian mailing list