[Mondrian] XMLA response size

[Matt Campbell]

Our first pass was pretty simplistic-- we just used a smaller Mondrian
schema then the default and compared numbers for the same queries.  Our next
pass will try to modify XmlaHandler to omit some of the overhead
information.

Our biggest issue has been around the Axis and OlapInfo, not the cellset,
although I'm sure that could be an issue as well if you have large results.

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.


On Fri, Aug 7, 2009 at 11:35 AM, Paul Stoellberger <
paul.stoellberger at aschauer-edv.at> wrote:

> +1
> How did you trim the XMLA response?
>
> Are you having any troubles when the XMLA response contains a large
> cellset? I'm not sure but i think i've read somewhere that this will cause a
> timeout somehow.
>
> It would be nice if the XMLA response could be a) trimmed b) compressed
> somehow
>
> -paul
>
> On 7 Aug 2009, at 17:19, Peter Tran wrote:
>
>  Matt,
>
> +1 This would an aweseome feature.  We also have the same issues with large
> XMLA.
>
> -Peter
>
>  ------------------------------
> *From:* mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org<mondrian-bounces at pentaho.org>]
> *On Behalf Of *Matt Campbell
> *Sent:* Friday, August 07, 2009 10:12 AM
> *To:* Mondrian developer mailing list
> *Subject:* [Mondrian] XMLA response size
>
>
> XMLA can be an extremely verbose protocol.  <ExecuteResponse> contains a
> lot of amount of information that may not be terribly relevant to the client
> application.  For example, the SlicerAxis specification includes each
> dimension in the cube not referenced in the query sliced at its default
> member (usually All).  <OlapInfo> also is not necessarily needed by a
> client.
>
> Our cubes have a very large number of dimensions (1000+), which results in
> a fair amount of overhead in XMLA processing, both in serialization and
> deserialization.  What we've been considering is enhancing the XmlaHandler
> to support a "verbose" property (defaulting to true).  If the property is
> set to false, the response will include only the information specifically
> relevant to the query.
>
> To provide some context, we have a set of test reports that run in roughly
> 230 seconds with the current XMLA content.  These same reports run in 70
> seconds with a "trimmed" XMLA response.
>
> Our client application is Cognos 8...we haven't yet tested whether
> Excel/O2X requires the extra metadata or not.
>
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
>
> _______________________________________________
> 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/533758c9/attachment.html