You are here: Performance > How to detect lengthy service operations

Detecting lengthy service operations

You can cause Pega 7 Platform to add a line to the Alert log when a service operation or parse rule operation takes an unusually long time. The line identifies the requestor, the service, and the value of the performance statistic.

Through prconfig.xml file entries or Dynamic System Settings, you can control whether alerts appear and the threshold value in milliseconds for each type of alert.

Statistics available

Five elapsed time statistics are available for most service types. When any of these five measured times exceeds a corresponding threshold, the system adds a PEGA0011 alert to the Alert log.

Three of the five statistics are available for listeners:

One of these values appears as the KPI Value in the alert message, the actual value in milliseconds that exceeded the threshold value.

Each PEGA0011 alert includes actual values for all five statistics, in the PAL Statistics field. Consult Performance tool — Statistics for services for definitions of these values. See PDN article Understanding the PEGA0011 Alert.

Changing the threshold values

  1. To change the pxTotalReqTime alerts, edit the prconfig.xml file to set a minimum value for the totalRequestTime element in milliseconds, and to control whether pxTotalReqTime alerts appear: For example, to set the value to 850 milliseconds, add this element:

    <env name="alerts/services/totalRequestTime/enabled" value="true">
    <env name="alerts/services/totalRequestTime/threshold" value="850">

  2. Stop and redeploy or restart the Pega 7 Platform server.
  3. Monitor the Alert log for messages.

The statistics for pxServiceImpMapReqTime, pxServiceOutMapReqTime, pxServiceActivityTime, and pxServiceParseRuleTime are included in PEGA0011. If you want to monitor the time thresholds individually, change the enabled setting to "true". Edit the default threshold value if necessary.

The default prconfig.xml settings for these alerts are as follows:

<env name="alerts/services/inboundMapping/enabled" value="false">
<env name="alerts/services/inboundMapping/threshold" "500">

<env name="alerts/services/outboundMapping/enabled" value="false">
<env name="alerts/services/outboundMapping/threshold" value="500">

<env name="alerts/services/activityTime/enabled" value="false">
<env name="alerts/services/activityTime/threshold" value="500">

<env name="alerts/parse/totalTime/enabled" value="false">
<env name="alerts/parse/totalTime/threshold" value="500">

As an alternative to the prconfig.xml file, you can use Dynamic System Settings to configure your application. See How to create or update a prconfig setting.

Notes

For information about alerts and services, see PDN article Testing Services and Connectors.

For information on all prconfig.xml file settings, see PDN article Configuration Settings Reference.

BPEL services operate asynchronously and are not monitored by this facility.

Important: The rule type Rule-Service-BPEL is deprecated. As appropriate, migrate to Service SOAP rules.

Related Topics Link IconRelated terms

Related Topics Link IconRelated information

UpIntegration Services category