<html><body bgcolor="#FFFFFF"><div>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. <br><br>______________________<div>Luc Boudreau</div><div><br></div></div><div><br>On 2009-08-07, at 12:01, Matt Campbell <<a href="mailto:mkambol@gmail.com">mkambol@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><br>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.<br>
<br>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.<br><br>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.<br>
<br><br><div class="gmail_quote">On Fri, Aug 7, 2009 at 11:35 AM, Paul Stoellberger <span dir="ltr"><<a href="mailto:paul.stoellberger@aschauer-edv.at"><a href="mailto:paul.stoellberger@aschauer-edv.at">paul.stoellberger@aschauer-edv.at</a></a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="word-wrap: break-word;">+1<div><br></div><div>How did you trim the XMLA response?</div><div><br></div><div>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.</div>
<div><br></div><div>It would be nice if the XMLA response could be a) trimmed b) compressed somehow</div><div><br></div><div>-paul</div><div><br><div><div><div></div><div class="h5"><div>On 7 Aug 2009, at 17:19, Peter Tran wrote:</div>
<br></div></div><blockquote type="cite"><div><div></div><div class="h5"> <div> <div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">Matt,</font></span></div> <div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">+1 This would an aweseome feature. We also have the same issues with large XMLA.</font></span></div> <div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">-Peter</font></span></div><br> <div dir="ltr" align="left" lang="en-us"> <hr> <font face="Tahoma" size="2"><b>From:</b> <a href="mailto:mondrian-bounces@pentaho.org" target="_blank"><a href="mailto:mondrian-bounces@pentaho.org">mondrian-bounces@pentaho.org</a></a> [<a href="mailto:mondrian-bounces@pentaho.org" target="_blank"><a href="mailto:mondrian-bounces@pentaho.org">mailto:mondrian-bounces@pentaho.org</a></a>] <b>On Behalf Of </b>Matt Campbell<br>
<b>Sent:</b> Friday, August 07, 2009 10:12 AM<br><b>To:</b> Mondrian developer mailing list<br><b>Subject:</b> [Mondrian] XMLA response size<br></font><br></div> <div></div><br>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.<br>
<br>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.<br>
<br>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.<br><br>Our client application is Cognos 8...we haven't yet tested whether Excel/O2X requires the extra metadata or not.<br>
<br><br></div></div></div> _______________________________________________<br>Mondrian mailing list<br><a href="mailto:Mondrian@pentaho.org" target="_blank"><a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a></a><br><a href="http://lists.pentaho.org/mailman/listinfo/mondrian" target="_blank"><a href="http://lists.pentaho.org/mailman/listinfo/mondrian">http://lists.pentaho.org/mailman/listinfo/mondrian</a></a><br>
</blockquote></div><br></div></div><br>_______________________________________________<br>
Mondrian mailing list<br>
<a href="mailto:Mondrian@pentaho.org"><a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a></a><br>
<a href="http://lists.pentaho.org/mailman/listinfo/mondrian" target="_blank"><a href="http://lists.pentaho.org/mailman/listinfo/mondrian">http://lists.pentaho.org/mailman/listinfo/mondrian</a></a><br>
<br></blockquote></div><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Mondrian mailing list</span><br><span><a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a></span><br><span><a href="http://lists.pentaho.org/mailman/listinfo/mondrian">http://lists.pentaho.org/mailman/listinfo/mondrian</a></span><br></div></blockquote></body></html>