Managing Performance

This page describes steps you can take to improve the performance of GI2.

Maintaining High Performance

Some elements are repeated throughout the universe for convenience, to reduce the potential for incompatibilities (see Troubleshooting Incompatibility), and also to improve report-query performance, including all time-related conditions that exist in more than one class:

[+] More Information

• DateRange—in the Activity, Agent Contact, Business Attribute, Contact Attempt, and Time classes
• PreSetAndDate—in the Activity, Agent Contact, Business Attribute, Contact Attempt, Summarized State, and Time classes
• PreSetAndDateRange—in the Activity, Agent Contact, Business Attribute, Contact Attempt, Queue, Summarized State, and Time classes
• PreSetAndDayAndTimeRange—in the Handling Attempt and Transfer classes

In previous releases, many of the reports referenced date-time keys that directly queried records in the DATE_TIME table; this required an additional join from the aggregate table to the DATE_TIME table—which is a sizeable table filled with thousands of rows of metadata. Beginning with the 8.0 release, some of these date-time references within the reports have been redirected to query the date and time fields within the reports’ base aggregate tables themselves—constituting a simpler design that requires one fewer complex join. As a direct result, performance for those reports improved over the 7.6 release.

As you build new reports or customize the provided reports, be sure to weigh the decision to employ date-time elements from the Time class with the decision to employ those elements—where they exist—from the universe class that supports your report’s underlying aggregate tables and views.

Optimal Time to Run Reports

The GI2 reports provide a snapshot of contact center and enterprise activity as of the most recent transformation and aggregation in the Info Mart database. For completed interactions in completed reporting intervals that occurred prior to the last transformation and aggregation runs, the reports provide consistent results each time the reports are run. However, results can differ for interactions that are still active, or for intervals that are incomplete. For example, running a month-type report mid-month yields results that differ from those that are obtained by running the same monthly report at the end of the month.

[+] More Information

Important

As with other Genesys applications, GI2 requires that your system GMT (Greenwich Mean Time) setting is accurate and synchronized among the servers in your environment.

The headers of each report display the report date (which is the date and time when the report was run) rather than the date and time when the most recent transformation job was run. In fact, the date and time when the most recent transformation job was run are not reflected in the report, even though it is that date and time at which contact center activity is reflected by the report data.

For the smaller aggregation levels, the variances in report results are more pronounced, given the configuration within the Genesys Info Mart application of the data chunk size that is to be transformed. Genesys Info Mart is an historical-reporting application, therefore you must give care to the interpretation of report results when you use GI2 as a near real-time tool to obtain daily reports (for example, when the day has not yet completed or has only recently completed).

Many factors contribute to latency in data availability between the date and time of the most recent transformation and aggregation run, and the date and time when the report is run, including the following:

• Scheduling of ETL jobs and job performance.
• Interaction volume, and the number of segments per interaction.
• Number of configured key-value pairs.
• Hardware and RDBMS that are used in your environment.
• Performance of ICON’s merge procedure.

Read more about these factors in the Genesys Info Mart documentation, and in the Genesys Hardware Sizing Guide.

Preventing WebI Server Problems

As your Info Mart database accumulates large amounts of contact center data, it becomes possible for users to request a report containing a very large amount of data. It is possible for such a report to stop the BI system, because when BI software retrieves data, it stores the data in memory. If the BO software has insufficient memory to handle a report with large amounts of data, or if the BI software is charged to handle requests from too many concurrent users running reports in parallel, an overflow occurs, and the software displays the following error message:
Unexpected behavior: Java heap space.

To prevent overflow due to insufficient memory, Genesys recommends that you perform one or more of the following procedures:

Manage the Memory Pool Size of Your Web Server	Microsoft Windows x86 applications are limited to 2 GB each for maximum memory pool size. The default memory pool size for the Tomcat web server application that is deployed with BO, however, is 1 GB. To increase this value, you can modify Tomcat configuration to set the maximum memory pool size to a value within the 1,200–1,500 MB range. Having this maximum number of pre-allocated memory blocks available for Tomcat enables memory allocation with constant execution. [+] Show Steps To change this setting for the Tomcat application, perform the following steps: On your Microsoft Windows platform, open the Tomcat program group and select Tomcat Configuration. In the Apache Tomcat Properties window, on the Java tab, set the Initial memory pool size to 512, and the Maximum memory pool to a value between 1,200 MB and 1,500 MB. Restart Tomcat. Refer to the SAP BusinessObjects Enterprise Administrator's Guide for additional information (see BO/BI documentation).
Manage the Virtual Memory of Your Host	When your computer lacks adequate physical memory to perform an operation or run a program, Microsoft Windows uses virtual memory to compensate. For efficient GI2 operation, set the amount of virtual memory to a size at least 1.5 times that of your host’s RAM. To adjust virtual memory configuration, refer to the documentation provided by Microsoft.
Manage the WebI Document Cache	Depending on the design of a GI2 report and the types of actions being performed against it, memory requirements vary. The peak memory usage for a Web Intelligence document occurs when you refresh a report, because BI must query the Info Mart database and transfer the entire dataset to the Web Intelligence server. File caching allows BI web services to handle very large attachments without buffering them in memory. File caching compromises performance because BO’s web services must process information by using files instead of memory. If file caching is not enabled, however, all JVM memory could be utilized when handling very large attachments and replication can fail. You can configure BI web services to use file caching for large transfers to a file and to use memory for smaller files. [+] Show steps To manage the Web Intelligence document cache, perform the following steps: Within the Central Management Console (CMC), click Servers. Setting Web Intelligence Processing Parameters Expand Service Categories, and open the properties of Web Intelligence Processing server. The figure Setting Web Intelligence Processing Parameters shows the default values in WebI properties. Set the value in the Document Cache Cleanup Interval field to 600 seconds. Set the value in the Cache Timeout field to 20 minutes. This value indicates how often the BI software will clear the document cache. If it is checked, clear the Disable Cache Sharing checkbox. Set the value in the Maximum Document Cache Size field to 10240 KB. Restart the Web Intelligence Processing server. Refer to the SAP BusinessObjects Enterprise Administrator’s Guide (or the Business Intelligence Platform Administrator Guide) and the relevant SAP Sizing Companion Guide for further information (see BO/BI documentation).