Performance Guidelines

This section provides a number of performance-related guidelines and recommendations to take into account when implementing Oracle Utilities Customer Cloud Service. This includes guidelines related to the following:

• Benchmarking, Scalability, Elasticity and Performance

• User Interfaces

• Initial Measurement Data and Event Processing

• General Topics

Benchmarking, Scalability, Elasticity and Performance

Oracle Utilities cloud services such as Billing Cloud Service, Customer Care and Billing Cloud Service, Customer Cloud Service (with Advanced Meter Solution) and Meter Solution Cloud Service are important components of a utility's solution set, and are:

• Mission critical in terms of revenue generation

• Highly configurable as many aspects of the solution are designed to be configured to meet market specific requirements

• Compute intensive, as many validation and calculation rules need to be applied during daily processing

• Time sensitive, as processing must be completed daily, on schedule and within a predefined (and strict) batch window

These cloud services have been designed and built from the ground up with all of these concepts in mind, but successfully implementing and operating them depends on a shared responsibility model with respect to Benchmarking, Scalability and Performance.

Who is Responsible for Scalability, Elasticity and Performance?

This is a shared responsibility between Oracle and the customer/implementer.

Oracle is responsible for the following in terms of the base cloud service:

• Scalability

• Elasticity

• Benchmarking

• Configurability

• Extensibility

• Performance of base product functionality, including:

• Embedded infrastructure and platform services

• Application framework

• Base product features and functions

• Configuration Migration Assistant

• Data Migration Tools

• Generalized/Specialized Data Extract

To verify the above, Oracle performs regular scalability benchmarking to confirm general solution scalability and elasticity, including:

• Vertical (scaling up), such as effectively utilizing more power (CPU, RAM, etc)

• Horizontal (scaling out), such as effectively utilizing more machines/servers

This scalability benchmarking is run on reference configurations and on very high data volumes, for example:

• 10M Billable Service Customers (CCS)

• 20M+ Utilities Device Data Channels for (MSCS)

The customer/implementer is responsible for the following in terms of the specific implementation:

• Performance optimization of customer configuration & extension logic

• Correction of customer data issues

• Functional testing

• Performance testing (initial and regression)

• Analysis of performance related issues

Customers/implementers should plan to run performance testing to verify that a their final configuration (that is, the implementation specific workload) meets expectations and preserves general solution scalability and elasticity.

Performance testing is:

• Executed by the customer/implementer

• Uses customer specific (final) configuration

• Run on final expected customer data migration volumes and so requires data migration to be complete, configuration to be finalized / functionally tested, and the solution running in a production sized environment (a full sized Test environment is provided for this purpose)

User Interfaces

• Zones: For better performance, user interface zones should be initially collapsed when not required for 90% or more of business processes. The initial state of zones (collapsed or not) can be controlled via the Portal Preferences tab on the User portal.

• Number of Records: The number of records returned to the user interface for a zone should be limited to 50 rows when building custom zones against large transactional tables.

• Screen Troubleshooting: To troubleshoot a screen in the user interface, click Preferences in the top right corner of the application and choose the Portal Preferences tab. Choose the appropriate portal and set all zones to "Initially Collapsed". Navigate back to the screen that has performance issues, expand the zones one by one, and measure the execution time of each zone. This should be an accurate step-by-step representation of the full screen execution.

• Performance Optimization: For optimal user interface performance, laptop users should ensure their computer is in high performance mode.

Initial Measurement Data and Event Processing

• Initial Measurement and Event Loading: The initial measurement data and event loading processes should be scheduled to avoid overlap with other intense processes. For instance, do not produce bill determinants when loading meter readings.

In addition, when processing measurement data coming from head end systems, payload files should be broken up into multiple files of approximately the same size (containing approximately 100 measurement records each) to allow for parallel processing.

When processing files of varying sizes, the chunkSize parameter can be used to facilitate improved processing throughput by distributing work across multiple batch threads. See Common Parameters in the Oracle Utilities Meter Solution Administrative User Guide for more information about the chunkSize parameter.

Due to high data volumes, web services should NOT be used to upload daily measurements. Projects should use Smart Grid Gateway payload processing to help avoid performance problems.

• Interval Measurement Processing: The system includes a number of Initial Measurement Data (IMD) monitor batch processes that can be used to minimize performance issues when adding large numbers of historical or backlog readings. These use the IMD as the processing work unit instead of the Device Configuration. This prevents situations in which an error on an IMD rolls back processing for all of the IMDS for a given device configuration. These include:

• D1-IMDV2 (IMD Monitor - Physical Devices V2): used to process initial measurements related to physical devices

• D1-IMDD2 (IMD Monitor - Deferred IMDs V2): used to process previously held or deferred IMDs

• D1-IMDM2 (IMD Monitor - Unattached MCs V2): used to process IMDs for standalone measuring components without a Device Configuration such as weather or price data

Refer to the Detailed Descriptions of these batch processes for additional information about each.

• VEE Rules: Any VEE Rules, whether provided as part of base product or custom developed, should be configured to query no more than 30 cumulative days of historical data (i.e., High/Low) to achieve an efficient data loading process.

• Raw Data: The raw data section of the initial measurement data record should not be populated in a production environment.

• Tracing: Use the Trace section of the IMD Log to troubleshoot VEE rules. When an initial measurement data is in Pending status, the Trace On button can be used to trace all VEE Rules fired during initial measurement data processing. Once processing is complete, view the Log tab of the initial measurement data and review the results in the IMD Trace Log zone. For any custom developed VEE rules, the average run time should be no longer than the average run time of other base product VEE rules.

• VEE and Usage Rule Configuration: VEE and usage rule configurations can affect performance; test runs are needed during implementation to tune these processes.

• Initial Measurement Data Business Objects: Avoid modifying the initial measurement data business objects.

General Topics

• Solution Updates: Oracle should be consulted before significant solution changes are made. For example, configuration and solution extensions, adding a large number of customers, network changes, new integrations, etc.