Background processing data in Pega Diagnostic Center

Pega Diagnostic Center (PDC) provides information about background processing performance that helps you to optimize data processing in your applications. You can make sure that your Pega Platform™ applications use resources efficiently.

PDC receives background processing information in snapshots once every ten minutes. The time of the last snapshot is the last time that the system last sent the data.

Background processing is useful when a process-intensive task or automation is required. With the background processing features in Pega Platform, you can offload tasks to help improve throughput and efficiency. By running tasks in the background, you improve system scalability and performance, and users can continue working on a case or other work.

For an overview of the resources in your system, PDC summarizes key statistics for each resource in the Metrics summary section. Each summary contains properties that are specific to the resource, for example, the total number of instances and the number of instances in each possible state. With this information, you can quickly check the state of each resource collectively.

You can export the data from the current and historical snapshots in CSV format by clicking Export to CSV. You can then use your spreadsheet software to investigate multiple issues by filtering, aggregating, and looking for specific agents, which can help you notice patterns or trends that lead to a better understanding of the causes of specific issues.

PDC provides information about the following background processes:

• Agents are the most basic processes. Each agent can perform only one task.
• Queue processors provide greater flexibility by choosing dedicated threads to process only a specific action. You can also control the number of threads and node types on which the processing runs.
• Agent queues are lists of agents and queue processors that determine the order in which the agents run.
• Job schedulers simplify item scheduling because you configure a single job scheduler rule instead of selecting multiple agents or queue processors.
• Listeners monitor designated parts of your application, waiting for inbound network requests or messages such as emails, specific files, or specific services.

Check your knowledge with the following interactions:

Job scheduler troubleshooting example

The following example provides some context about what information to look for when resolving specific problems: Users receive emails daily with statistical data. However, the emails are usually late and contain outdated information. To investigate the issue:

• You can check whether a job scheduler takes more time than usual to fetch the data. On the Job Scheduler landing page, you can see the last time the job scheduler ran.
• If the last run was long ago, that could indicate that the job scheduler stopped running. If you see a noticeable spike in duration time, it could mean that the job scheduler is in an infinite loop.
• If the last run time is as expected, you should check the duration time, which shows how long it took for the job scheduler to process data. By inspecting historical snapshot data and identifying when the duration spiked, you can determine when the problem occurred.
• You can check if there were any patch deployments during that time or if the system was otherwise changed.

Check your knowledge with the following interactions: