[Mondrian] XMLA response size

Luc Boudreau lucboudreau at gmail.com
Fri Aug 7 12:14:46 EDT 2009


Mondrian should use the compression algorithm that clients would  
request in their request HTTP header. That way it would be easy for  
clients like olap4j to trigger compression or not.

______________________
Luc Boudreau


On 2009-08-07, at 12:01, Matt Campbell <mkambol at gmail.com> wrote:

>
> 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] 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
>
>
> _______________________________________________
> 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/880fb673/attachment.html 


More information about the Mondrian mailing list