[Mondrian] XMLA response size
mkambol at gmail.com
Fri Aug 7 14:39:43 EDT 2009
Any thoughts about suppression of Dimension default members from the slicer
axis? That's the other area of substantial overhead for us.
I like the idea of the XMLA request specifying the content it wants with a
property like Content=DataWithoutInfo. We would need to find some way to
modify the Cognos XMLA request before passing it on, but that shouldn't be
On Fri, Aug 7, 2009 at 2:23 PM, Julian Hyde <jhyde at pentaho.com> wrote:
> 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!
> Mondrian mailing list
> Mondrian at pentaho.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mondrian