How to maximize performance of the application

 

 

   Overview:

   I.   Design of OLAP Databases and views in the web client

   II.  Client Browser

   III. Client Hardware

   IV.  Tomcat Configuration

   V.   Server Hardware

 

   I. Design of OLAP Databases and views in the web client

   The application can internally handle very large dimensions, databases

   and cubes but browsers need some time to show a huge number of elements

   in a combo box or in a table. Especially the dimensions dropped to fill

   the horizontal or vertical axis in the 2-dimensional table of a view

   should be designed or structured in a way so that not too many dimension

   elements are shown at one time. This can be done by structuring the

   original OLAP dimension with enough consolidated elements.

   You can use subsets and local filters for a dimension in the web client

   to avoid having too many root elements or child elements directly

   under a parent.

 

   II. Client Browser

   The speed of different browsers concerning script execution varies a lot.

   - IE7, IE6 and IE5 are slow and are not recommended if possible for you.

   - Internet Explorer 8 is about 3 times faster than IE7.

   - Firefox 3.x is about 10 times faster than IE7.

   - Safari is about 15 times faster than IE7.

   - Iron and Chrome are about 30 times faster than IE7.

   - We recommend using IE8, Firefox 3.x, Safari, Chrome and Iron.

     

   Still, for views with a large number of displayed table cells the time

   for the script execution may appear to be too long for the used browser.

   In this case the browser shows requests asking if you want to continue

   executing the script or stop it. If you stop it, only this specific view

   remains in an undefined state and you need to reopen it.

   You can confirm these dialogs every time they appear or you can modify

   the default value of the script timeout for your browser:

 

   Firefox

   Firefox allows you to deactivate the appearance of the info dialog

   directly in the dialog shown in case of scripts that run a long time.

   You can also modify the time how long it takes before a warning appears:

   a. Type ‘about:config’ in Firefox's address bar

   b. Filter down to the value for ‘dom.max_script_run_time’

   c. Change the value (in seconds) to something higher than the default

      (which is 10 seconds)

   d. Filter down to the value for ‘dom.max_chrome_script_run_time’ helps

      to set the same value for applications with chrome rights

 

   Internet Explorer

   Please find the information to modify the script timeout for IE here:

   (based on the total number of executed script statements)

   http://support.microsoft.com/kb/175500  (in your browser’s language)

   http://support.microsoft.com/kb/175500/en-us/  (in English)

 

   Safari

   Please find information on how to deactivate "Runaway JavaScript Timer"

   in Safari by using the search function for exactly this term in the

   safari help (key F1).

 

   Iron and Chrome

   These very similar browsers actually don’t need an option to deactivate

   the script timeout or set the timer to a customized value, because - in

   contrast to all browsers mentioned above - they have a nifty feature:

   Although they also show a warning, the script execution is not paused,

   so that the user does not have to interact with the dialog in order to

   let the script continue its execution.

  

   III. Client Hardware

   As the performance of the script engine of a browser also depends on

   the CPU speed of the client machine a faster processor is helpful.

 

   IV. Tomcat Configuration

   The default value for "Maximum memory pool" of the tomcat is low

   after installation. Set it to a higher value suitable for the system.

   We recommend 1024MB. You can do this on a windows system within the

   "Apache Tomcat Properties" or on a linux system within the file:

   /tomcat/bin/catalina.sh

   with a line like:

   CATALINA_OPTS="$CATALINA_OPTS -Xmx1024m"

 

   V. Server Hardware

   The tomcat server can be run on a workstation for testing purpose,

   but for better performance it should be run on a server machine.

   For example, Tensegrity runs the online demo on a linux machine with

   only one single core processor. For a production system we recommend

   dual core and/or multi processors. We also recommend 2GB RAM or more.