You may want to keep more data with a longer history of time intervals in Java Performance Monitoring.

For example, you want to keep daily intervals for 14 days instead of only 7 days. 

For PI releases 7.31 and 7.4, an enhancement was introduced that allows you to extend the retention period for persistent performance data. You can call the following servlet and set a custom value for the retention period using the URL parameter PeriodConfig of PerformanceDataQueryServlet.

http://<host>:<port>/mdt/performancedataqueryservlet?PeriodConfig=…

The following period types are available:

  • MINUTE: performance data for the last hour, aggregated every 15 minutes;
  • HOURLY: performance data for last 24 hours, aggregated every hour;
  • DAILY: performance data for last 7 days, aggregated every day.

For example,

1) If you’d like to see the daily performance data for the past 14 days in the Performance Monitor tool, you can use the servlet:

http://<host>:<port>/mdt/performancedataqueryservlet?PeriodConfig=DAILY=14

(14 = 14*1)

2) If you’d like to see the hourly performance data for the past 30 days in the Performance Monitor tool, you can use the servlet:

http://<host>:<port>/mdt/performancedataqueryservlet?PeriodConfig=HOURLY=720

(720 = 30*24)

3) If you’d like to see the performance data for the last 24 hours by 15-minute intervals in the Performance Monitor tool, you can use the servlet:

http://<host>:<port>/mdt/performancedataqueryservlet?PeriodConfig=MINUTE=96

(96 = 24*4)

4) You can also change all interval types with one servlet call and don’t have to call it 3 times:

http://<host>:<port>/mdt/performancedataqueryservlet?PeriodConfig=DAILY=14,HOURLY=720,MINUTE=96

Note: If you call this servlet (HOURLY=720), it means “keep the hourly intervals for 720 hours (30 days)”, not “keep 720 hourly intervals”. The URL parameter PeriodConfig defines the retention period for performance data displayed in performance monitor tool, not the number of intervals displayed there. An interval only appears if there are actually messages in this interval. For example, if you don’t have messages in the night, then some hour intervals might not appear.

Note: The new, custom values are persistent in the database and survive in a system restart and deployment of updates and upgrades.  But if the performance data collection was disabled (parameter profile.performance.runtime of the service “XPI Service: AF Core” as described in note 1636215) and again enabled, then the values are reset to the default (DAILY=7, HOURLY=24, MINUTE=4).

Note:  Keeping too many entries can cause the respective database table to grow. Therefore you should always adjust the number of stored entries to the required minimum and consider exporting them to a remote database or file. The number of entries/rows in the table can be calculated with the following formula:

    Rows = Nr. of Server Nodes * PI Scenarios * (daily + hourly + minute)

So if you keep 96 of the 15-minute intervals and 720 of the 1-hour intervals and 14 of the 1-day intervals,  that means 830 entries. This 830 is then multiplied by the number of scenarios and the number of server nodes, for example, if you have 1000 scenarios and 10 server nodes, then you will have 8.3 million entries in the DB table XI_AF_PROF_PERF_AC.

************

Also you may want to know if parameter profile.performance.cache.cleanup is relevant to the data retained time in performance monitor tool. The answer is no.

Some background information:

1) Performance Monitor first keeps non-final messages in a memory cache. Those are messages in Delivering, To Be Delivered, System Error and Waiting.

If there are too many non-final messages piling-up in the memory (e.g. some PI scenario fails and there are thousands of System Error messages in the system), the collected performance data for the non-final messages are swapped-out from the memory cache to the DB table XI_AF_PROF_PERF_CA to prevent unlimited growth of the memory cache and out-of-memory errors.

The parameter “profile.performance.cache.cleanup” determines how many days elapse until the old data is deleted from the DB table XI_AF_PROF_PERF_CA. Please note that this data is only for the non-final messages, which are not part of what we can see in the Performance Monitor tool.

2) If a message goes into a final status (Cancelled or Delivered), it is removed from the memory cache and aggregated into the final data sets. This Performance Data is summed-up in an aggregated data entry according to the time intervals.

This aggregated data is stored in DB table XI_AF_PROF_PERF_AC (please note that the table name here is different from the previous one) and this is the data we can see in the Performance Monitor tool. How long we keep this aggregated data can be changed with the servlet above.

Related Content

Note 2006366 – Performance Monitor: change number of retained time intervals

Note 1993988 – Performance Monitor: improvements and fixes for Java PerfMon 2

Note 1790113 – Performance Data: automatic query of data with a servlet

External Collection of Message Processing Statistics from Advanced Adapter Engine of PI

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Ranjith Jacob

    Hi Tina,

    THank you for this blog. I believe this is specific to PI/PO. do you have same configuration for just portal EP systems?

    thanks,

    Ranjith

    (0) 
    1. Tina You Post author

      Hi Ranjith,

      This blog is specific for PI/PO system. I’m not very familiar with EP system, so I’m not sure if there is any similar configuration for portal EP systems.

      Best Regards,

      Tina

      (0) 

Leave a Reply