[Mondrian] XMLA response size

Matt Campbell mkambol at gmail.com
Fri Aug 7 13:52:50 EDT 2009

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

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

On Fri, Aug 7, 2009 at 1:00 PM, Julian Hyde <jhyde at pentaho.com> wrote:

>   Matt Campbell wrote:
> Regarding compression:  Analysis Services 2005+ uses a compressed binary
> representation of their XMLA as the default mechanism, but their binary
> protocol is proprietary.  Without an open standard we'd have no way to
> compress the XMLA in a way that clients could understand.
> Matt,
> I tend to think the same way as you on matters of standards compliance. I
> think that by defining a very verbose standard, and then making compression
> a non-standard extension, Microsoft sent us all down the river and kept the
> only paddle.
> XML compression is the obvious solution here. The compression rate should
> be so high, and so easy, that it will improve CPU utilization as well as
> bandwidth. Absent an open standard, if we were to use a widely used, open
> source XML compression algorithm, I think it would be easy to incorporate
> into any client that wants it.
> Specifically, could you incorporate it into your client? I'm thinking that
> we'd have an HTTP header in the request and response describing the
> compression algorithm to use, and you'd have to interject a
> compressor/decompressor.
> Assuming you could add a compressor/decompressor to your client, let's
> continue to consider that as an option. Does anyone know of any candidate
> compression algorithms? I suspect that it would be a compression algorithm
> targeted at XML specifically -- because of the characteristic
> problems/opportunities in XML data -- but we could consider others.
> 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/cb0e9040/attachment.html 

More information about the Mondrian mailing list