SQL Server Analysis Services (SSAS) is becoming increasingly popular as an OLAP platform for business analysts. There are many tools available for enhancing the analysts’ ability to process data and get meaningful insights. These vary from direct queries in Excel to custom applications. For example, using PowerPivot to extend Microsoft Analysis Services directly into an Excel Workbook, you can then use Excel to build and explore an OLAP model using pivot tables and other techniques. One thing you can generally be sure of is that this will result in processing very large sets across the network.
There are two primary areas where SSAS will generate a lot of network activity:
- When loading the warehouse, SSAS will communicate with MS SQL Server OLTP databases to bring up to date information in the OLAP database (SSAS Server).
- Like the PowerPivot Excel example, business analysts will connect to the SSAS Server to run their analyses and reports.
One example is a company that collects consumer data and makes it available for analysis of trends and buying patterns so that retailers can make decisions on products, product characteristics, prices, and timeframes for selling the products. This scenario takes transactional data such as customer purchases, product inventory, etc. from each store and then this data is moved and transformed into an OLAP (SSAS) Server. Now it is available for business analysts using tools like Excel connected via PowerPivot to analyze the data. The figure below depicts this scenario:
In the case of SQL Server OLTP databases, they use the Tabular Data Stream (TDS) protocol to transfer the data from SQL Server to the SSAS Server. SSAS uses XML for Analysis (XMLA) over either TCP or HTTP for accessing the instance. This is a listener service that uses port 2383 as its default port.
In the scenario above, with the large amounts of data being moved across geographically dispersed locations, it can take a significant amount of time to 1) get the SSAS OLAP Server loaded, and 2) access the OLAP data from the SSAS clients. The last thing you want is a highly paid PhD-level business analyst losing productivity waiting for data to download. Of course, even if the analysts and all the databases, both OLTP and OLAP, are co-located, you may still suffer from network congestion with large data volumes.
Some companies address this performance issue by building data marts – which are effectively smaller data warehouses where data may be either categorized or re-summarized to reduce the data set. This is in effect a data warehouse on the analyst’s desktop. At this point, the primary performance constraint may be processor speed and memory on the analyst’s machine.
Another option is to try to reduce the network traffic between the OLTP-SSAS servers and between the SSAS Server and Clients. NitroAccelerator from Nitrosphere can accomplish this by, in the first case, optimizing the TDS protocol with compression and other techniques to speed the loading of the OLAP/SSAS server. In the second case, NitroAccelerator now supports the XMLA listener and optimizes the TCP/HTTP traffic between the SSAS Server and SSAS Clients. The example above is with a real life customer where they located their OLAP server in the cloud. They got two benefits from NitroAccelerator: 1) They significantly reduced data charges for downloading from the cloud-based OLAP server, and 2) They improved performance on the client side by 90%!
With increasing use of SSAS in conjunction with use of cloud-based databases (OLTP and OLAP) you will want to consider the network costs as well as performance when it comes to moving large amounts of data for data warehouse needs.
For more information on Nitrosphere and/or to try NitroAccelerator, please visit http://nitrosphere.com/trial/
If you have a performance problem, you can always hire me.
Reference: Pinal Dave (http://blog.SQLAuthority.com)
First appeared on SQL SERVER – Analysis Services and the Network Performance