[Mondrian] XMLA response size

Matt Campbell 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
> client.
> 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
> milliseconds).
> 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
> mandatory.
> 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!
> http://www.freepatentsonline.com/y2006/0026167.html
> Julian
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20090807/f19a346e/attachment.html 

More information about the Mondrian mailing list