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:
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.
• 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.