Sizing Performance Analytics Engine instances

A Real User Analyzer component provides data to Performance Analytics Engine instances.

Note

A BMC Real End User Experience Monitoring system recognizes only one instance for processing queries. If you set up multiple instances, the system uses (for queries) only the instance that was added first.

Key factors in the performance of a Performance Analytics Engine instance are:

  • The I/O capacity of the disk array serving as its storage location
  • The number of files that an instance opens

There is no limit to the number of Analyzer instances that can provide data to a Performance Analytics Engine instance. However, consider the following guidance based on performance testing:

  • One Performance Analytics Engine instance can process up to 10,000 hits per second, using the low-profile configuration (as described in the following table). Medium- and high-profile configurations can process more than 10,000 hits per second, although formal test results are not currently available.
  • Do not assign more than three high-profile Analyzer instances as data providers to a low-profile Performance Analytics Engine instance.

  • Compressing data on the Analyzer before providing it to a Performance Analytics Engine instance results in higher CPU usage but requires less network bandwidth.

    Recommendations

    Basic guidelines for choosing whether to compress data include:

    • Uncompressed data allows processing of higher traffic volumes.
    • Deploying a Performance Analytics Engine instance on the same host as the Analyzers that are feeding it, and then using local storage, prevents network bandwidth issues.

Performance Analytics Engine sizes

For each Analyzer that is feeding data to a Performance Analytics Engine instance, a minimum of three write-only files are opened on the disk array to insert object, page, and session data. As the time frame of the data crosses various time boundaries (hour, day, month, and so on), each instance might need to open additional files on a temporary basis. Typically, the number of open write-only files doubles during only a few minutes and then returns to normal. The same conditions might occur if the data being processed is heavily delayed or out of order due to network lag between Collector and Analyzer components.

Queries also open multiple files for simultaneous read-only processing, but only 20 read-only files can be opened.

When determining hardware requirements for a Performance Analytics Engine instance, use the following considerations in your estimates:

  • Typical disk throughput is 50 megabytes per second. However, depending on your traffic, the amount of content that you are capturing, and the number of custom fields that you have defined, daily throughput could range from 100 gigabytes to 1 terabyte.

  • For each Analyzer instance that you add, the system maintains a steady state of three write-only files, spiking higher than that when necessary (up to double or more if the data is dramatically out of order). Files are closed and new ones are opened whenever a file reaches either the maximum allowable size or the maximum allowable duration. A file might also be closed when it stops receiving any data. These limits are controlled by system properties that can be accessed only by a BMC Software Consultant or Customer Support representative for the purposes of specialized tuning.

    Note

    These settings rarely require adjustment.

  • A Performance Analytics Engine instance opens up to 20 read-only files for simultaneous processing. The system dedicates one thread for each open file. To improve the performance of your queries, you can improve the disk-array hardware or you can ask a BMC Software Consultant or Customer Support representative to raise the limit on the number of files that can be opened for reading.
  • Because of fixed disk-array I/O limitations, increasing memory or processor resources is unlikely to have a dramatic effect on performance. However, the specifics of your hardware might be part of the issue.
Warning

Ensure that the disk array does not allow the system's read activity to starve its writing capacity. Otherwise, data loss will occur, as the write capacity fails to keep up with the volume of data waiting to be written.

The management of storage space is based on a rolling-buffer data structure (first in, first out—FIFO). When a storage disk reaches its maximum capacity, new data overwrites the oldest data.

Related topic

System-requirements

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*