Performance Guidelines
This section provides a number of performance-related guidelines and recommendations to take into account when implementing Oracle Utilities Meter Solution Cloud Service. This includes guidelines related to the following:
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
• Content 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 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)
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 2,000 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.
Usage Transactions
• Number of Usage Transactions: The number of usage transactions per day should not exceed 20% of the total service point volume.
• Daily Scalar Usage Rule: The Daily Scalar Usage usage rule should be used when calculating usage for frequently read scalar channels (one or more reading per day). This rule only exports the beginning and ending readings.
• Vector and Service Quantity Math Rule: Only use the Vector and Service Quantity Math rule when other usage rules cannot perform the same calculations. For example, although the Vector and Service Quantity Math rule can perform TOU mapping, you should use the Get TOU Mapped Usage rule if TOU mapping functionality is the only requirement.
• Measurement Data in Usage Transactions: Minimize the amount of measurement data included in the Usage Transaction results, as individual interval records included with the usage transaction will slow down processing. Saving derived interval data and sending the data to an external system via the Save Interval Vector and Extract Interval Data options on the Vector and Service Quantity Math and Get Interval Data usage rules can have a noticeable impact on usage transaction processing. Usage transaction processing can be improved by up to 45% if extraction of interval data is eliminated. Use of these options should be limited to situations in which they are absolutely required.
• Interval Data Export: Usage transactions should not be used as an ETL tool to perform the mass export of interval data.
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.
• Troubleshooting Screens: 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.
Commands and Events
• Meter Events: Only meter events that have significant business value should be imported into the cloud service. These are generally events that involve billing or outage processes. Superfluous events such as hourly meter communication confirmations should not be sent to the service.
• Meter Commands: Meter command processing should be configured such that it does not slow billing processes and can be supported by the advanced metering infrastructure (AMI) network. For example, meters should not be pinged every five minutes.
General Topics
• Performance Tests: Performance tests should be performed on all configurations to ensure daily processing windows are adequate. This includes configurations for: usage rules, VEE rules, aggregations processes, etc.
• Solution Changes: Oracle should be consulted before significant solution changes are made. For example, adding new meter channels, adding a large number of meters, network changes, or new integrations, etc.