Because some Subjects, dashboards and queries  can access a large number of records, even when summarising the data, there are a number of things you can do to significantly improve the performance of these.


1.    Upgrade to DataPA OpenAnalytics V5.5 or above.


The 5.5 version of DataPA OpenAnalytics have a number or significant performance improvements in particular when dealing with large datasets. 


2.    Remove extra fields from queries when using dashboards


A simple way of improve the performance of both refreshing of dashboards and the speed with which the charts are rendered is to remove from the query any fields which are not used in the dashboard for any objects. 


3.    Make sure the AppServer temp directory has enough space 


While a DataPA query is running on an AppServer a temp table is being built server side up by the DataPA routines. This temp table is returned as the result when the query completes.  While the temp table is building most of it is written to a DBIXXXXXXX file in the TEMP folder of the AppServer. By default this will be the Progress working directory but it can be changed using the –T <directory> start up option on the srvrStartupParam property of AppServer that you are using. Whatever directory you choose for this it is vital that you choose one which is on a drive that has plenty disk space available. A rule of thumb to plan with would be 1GB for each AppServer agent that is able to run DataPA requests. 


4.    Set Java heap size parameter on AppServer to a higher value than the default 


You may need to do this is when refreshing your query or dashboard you get the following error: 

Broker System failure: Invalid state for deallocate: Current state = STATE_RECEIVING (7249). (7209)

Broker System failure: <error message>. (7209) 

This means that a Java exception occurred that was caused by the Java VM not having enough memory to hold the data being passed back from the AppServer. 

To get round this problem you need to increase the heap size available to the Java VM and to do this you need to amend the AppServer configuration on the machine which runs your DataPA AppServer. 

The line highlighted in yellow needs to be inserted to achieve this and then the AppServer needs stopped and restarted. 


[UBroker.AS.bigsports]
    appserviceNameList=bigsports
    autoStart=1
    brkrLogAppend=0
    brkrLoggingLevel=3
    brokerLogFile=c:\openedge\wrk\bigsports\bigsports.broker.log
    controllingNameServer=NS1
    initialSrvrInstance=1
    jvmArgs=-Xms128m -Xmx1024m
    maxSrvrInstance=2
    mqBrokerLogFile=@{WorkPath}\bigsports.mqbroker.log
    mqServerLogFile=@{WorkPath}\bigsports.mqserver.log
    operatingMode=Stateless
    portNumber=7187
    PROPATH=c:\openedge\wrk\datapa.pl;@{WinChar Startup\PROPATH};@{WorkPath}
    srvrLogAppend=0
    srvrLogFile=c:\openedge\wrk\bigsports\bigsports.server.log
    srvrLoggingLevel=3
    srvrStartupParam=-db c:\openedge\wrk\databases\bigsports\bigsports.db
    srvrStartupProc=startup.p
    uuid=55c948639f186661:-420618c3:146a32707f2:-4a33
    workDir=c:\openedge\wrk\bigsports
 


The values shown in the setting above should normally suffice but this Progress KB details what the settings options are should these need to be amended: 

http://knowledgebase.progress.com/articles/Article/P188382


 5.    Set the TCP connection timeout 


Sometimes when refreshing a dashboard or query that takes some time the following error can be seen: 


Communication layer message: Client Communications Failure - Connection reset by peer (8409).(7175) 


This error is caused by the TCP connection from DataPA to the AppServer timing out. The default settings on a DataPA connection allow the dashboard or query to run for 41 minutes and 40 seconds before returning with the error. 


This can be amended and it is sensible to change these settings prior to running and dashboards, reports or queries. 


This timeout is controlled by two settings which you can set on the Tuning tab of the Connection Details on the System in the Analytics Engine. 


 Property
Description
 TCP Client  Retry
 This property sets the number of times that DataPA should check with the AppServer to see if the request is  complete before  giving up and terminating the connection to the AppServer.
 TCP Client Retry  Interval
 The amount of time in hundredths of a second that DataPA should wait between checks with the AppServer  to see if the request  is complete.


By default the TCP Client Retry is set to 1000 and the TCP Client Retry Interval is set to 250.


This calculates as 1000 x 250 = 250,000 hundredths of a second = 2,500 seconds = 41 minutes and 40 seconds. 


If you change the TCP Client Retry to 2000 and the TCP Client Retry Interval to 1000 then that calculates as 2000 x 1000 = 2,00,000 hundredths of a second = 10,000 seconds = 2 hours 46 minutes and 40 seconds and gives the query 8 times longer to complete. 


6.    Memory on DataPA OpenAnalytics Enterprise machine 


DataPA recommends that the minimum memory you should have on a server that is running DataPA OpenAnalytics Enterprise is 16GB. 


When publishing large dashboards to DataPA OpenAnalytics Enterprise these can be set to auto refresh which involves them being loaded into memory. 


Also when users work with the dashboards using either the web portal or the mobile apps they will be loaded into memory by the web server as well. 


This means that when you have a number of larger dashboards in use then the amount of memory used on the server may be significant. 


A rule of thumb is for each large dashboard published you should add an additional 1GB of RAM to the server. In addition another 1GB of RAM should be added for each large dashboard which is published and set to auto refresh. 


If you consider an example where you have a 10 large dashboards published and 5 of those auto refresh. The table below shows how you would go about calculating how much memory would need to be made available on the server running DataPA Enterprise. 


 Memory Type

No. 

Size 

 Total 

 Base memory
  

16 GB 

 Large dashboards published

10 

1 GB 

10 GB 

 Auto refresh dashboards  published

1 GB 

5 GB 

 TOTAL
  

31 GB 


So 31GB of RAM would be recommended and you would round this up to the available multiple which in this case would be 32GB.