This article will help you to identify the cause of low performance occuring in one of Panorama applications.

Since any BI solution is a complexity of dependend services, drivers and applications, those, and many more parameters can affect performance.

Performance tests described in this article should be performed to identify the cause.

Prior taking steps on enhancing and measuring performance through NovaView application, it's highly recommended to enhance and measure performance on OLAP side. The guides on OLAP performance can be downloaded here.

The tests described in this article, should help find the bottle-neck, if that caused in NovaView application.

Please restart Panorama, IIS and Analysis Services before each one of the big tests. Do not restart the services before each one of the sub-tests. Before proceeding clean the application event log on the Panorama Server.

In a Panorama/MSAS BI solution there are many components that can be blamed for low performance:

1. Cube design, MSAS configuration, storage and aggregations
2. Panorama MDX query, view design
3. Panorama server configuration, hardware
4. Network delay, web issues, SSL, IIS
5. Number of concurrent users

The following tests should help find the bottle-neck. Please restart Panorama, IIS and AS services before each one of the big tests. Do not restart the services before each one of the sub-tests. Before proceeding clean the application event log on the Panorama Server.

1. Eliminating all the web environment.

   Let's work with the NovaView Desktop client which is installed on the NovaView server. Open some briefing book and select 3 views you'd like to focus on. Run the view as is and estimate the time it takes from clicking the view in the briefing book and till the numbers show up. Click the views again while in the same session and measure the time again. Sometimes second run of the views will be much faster. Now select some view and do some operations in this view (always measure the time it takes for the operation to complete):

   1. Slice on some member (real, not calculated)
   2. Measures on columns vs. sliced on one measure
   3. Calculated measures vs. real ones
   4. Drill down some dimension in the grid to the very low level
   5. Evaluate nesting performance

   At this point we should know something about the cube performance and about views design/Panorama MDX generation for your cubes. It is beneficial if you can have the AS and Panorama servers not busy (CPU/memory) during these tests.

2. Checking simple web interface

   Make sure Panorama's Web Access default web page welcome.htm is available (open the http://servername/panorama/welcome.htm). Using NovaView Administrator make sure Panorama Cache is disabled (Right-click on NV Administrator -> Properties -> Database).
   Use Sun JVM only on the client side and run the same 3 reports with the welcome.htm page. Try to keep Analysis Services and Panorama servers not busy during these tests. No need to perform all the operations on the views from the Desktop test again. Do this test twice:

   1. First time from the Panorama Server machine
   2. Second time from a real user's machine
   Now we should know how Panorama server performs with no load, but still using all the technology + network delay should be determined. Next is to start testing high load and concurrent connections.

    

3. Start performance monitor on the Panorama Server and on the AS server.

   pointing to the same view(s) we tested before. Enable Panorama Cache on

   Monitor CPU and Memory (real, virtual, add some most important measures). Prepare a page with 10 Panorama components the server side. When calling the applets, use FLAG parameter to control cache and repeat the test twice, once with and once without the cache. For each one of the following tests, access the page, measure the time it takes for all the applets to complete load, then press refresh on the browser and measure the time again:

   1. Access the page from the server with no cache
   2. Access the page from the server with cache
   3. Access the page from a real user machine with no cache
   4. Access the page from a real user machine with cache
   Let's ask more than one user to access this page now creating more significant load on the server. Keep on monitoring the CPU and Memory, but start the logging from scratch. Ask 10 people (it can be just 10 browsers) to access the same 10 components page approximately in the same time. Repeat steps 3.c and 3.d with 10 users.

    

4. Finally, let's test if Java environment has any impact on the system.

   Repeat test 2.b while accessing the welcomeF.htm instead of welcome.htm. Repeat the test with 10 open browsers. If end-user machine performance is different from the browser tests on the Panorama server, try to use some network monitoring tool to check the amount of data passed through. In addition enable IIS logging and log everything.

In the end of all this please provide us with:
Your personal impression and feedback:

• Time measurements
• Application event log saved as EVT file from the Panorama Server
• Performance Monitor and/or network watcher results for test 3 and/or 4
• Description of any errors or exceptional behavior/performance you noticed during the tests

 

• All versions