Wednesday, April 06, 2005

Analysis Services Network Performance Part III

Analysis Services Network Performance Part III

Many people have raised a few good points in reply to my last positing. The consensus is that many people would assume that naturally verbose XMLA would be a slower solution than the binary connection protocol that PTS uses.

In fact if you try to connect with the uncompressed XMLA stream that will be the case, IIS compression reduces the network traffic by around 80-90% due in part to the repetitive nature of XMLA.

However for me the key difference is more fundamental, it is the model of connection and querying that is different.

We treat the server almost like a web service in that we submit a query and then get back a response with pretty much what we asked for. This is wildly different to PTS which will return what it thinks you asked for, plus a load of other stuff.

My understanding is that PTS on the client will take your MDX query and break this down into a number of queries; it then gets the results of these queries and then passes them back to the client tool.

In this process you may find that the data shipped back is at a lower level that you requested in your query, or contains more members than you asked for because PTS is trying to be smart about caching on the client.

This model makes sense on a LAN because you have a large amount of bandwidth, however on a WAN this model gets messy real quick. What the XMLA SDK does is give us the opportunity to do the PTS bit back on the server and then just ship back the data that we asked for in the first place, this gives you a much thinner way of providing your users with the service that they require.

If you want some more specifics in info of report times vs location etc please contact me