Performance problems in Pega applications do not always come from slow database queries or poor integrations. Sometimes, the problem is much closer to the runtime.<\/p>\n\n\n\n
One common cause is excessive data stored on the Clipboard<\/strong>.<\/p>\n\n\n\n The Pega Clipboard acts as runtime working memory during case processing. It can hold case data, embedded pages, Page Lists, Page Groups, Data Page content, integration responses, parameters, and temporary data.<\/p>\n\n\n\n The Clipboard itself does not cause performance problems. Instead, issues can occur when an application stores too much data for too long.<\/p>\n\n\n\n A Page List is a good example.<\/p>\n\n\n\n A Page List with a few records is usually fine. However, storing thousands or millions of complex pages can quickly increase memory use. As a result, processing can slow down and garbage collection can increase.<\/p>\n\n\n\n In severe cases, excessive Clipboard growth can affect requestor or JVM stability.<\/p>\n\n\n\n This article explains how Page Lists can create production performance problems. It also covers common causes, troubleshooting steps, and practical design rules for high-volume Pega applications.<\/p>\n\n\n\n The Pega Clipboard works as the runtime working memory<\/strong> for application processing.<\/p>\n\n\n\n A typical case can contain structures such as:<\/p>\n\n\n\n The Clipboard can also contain temporary pages and data retrieved during processing.<\/p>\n\n\n\n For example, an integration may return customer information. The application may then copy that information into a temporary structure for validation.<\/p>\n\n\n\n These objects use runtime memory while the requestor retains them.<\/p>\n\n\n\n Therefore, developers should consider two key factors:<\/p>\n\n\n\n Data size \u00d7 Data lifetime<\/strong><\/p>\n\n\n\n A small object that exists for a short time usually has little impact.<\/p>\n\n\n\n In contrast, a large object that remains in memory during a long-running operation can become expensive.<\/p>\n\n\n\n This difference becomes especially important in high-volume processing.<\/p>\n\n\n\n Page Lists are useful for storing collections of related objects.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n This design is normal.<\/p>\n\n\n\n However, problems can arise when a Page List becomes a container for an entire dataset.<\/p>\n\n\n\n Consider a file-processing application with 500,000 records:<\/p>\n\n\n\n The design may work well with a small test file. However, production data can create a much larger runtime structure.<\/p>\n\n\n\n The situation becomes more serious when every Page List item contains:<\/p>\n\n\n\n Therefore, record count alone does not determine memory use.<\/p>\n\n\n\n The complexity of each page<\/strong> also matters.<\/p>\n\n\n\n Nested collections can make a Page List much more expensive.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n Now imagine thousands of customer pages. Each customer may contain several order pages.<\/p>\n\n\n\n As a result, the number of Clipboard objects can grow quickly.<\/p>\n\n\n\n Therefore, developers should ask more than:<\/p>\n\n\n\n “How many records am I loading?”<\/strong><\/p>\n\n\n\n A better question is:<\/p>\n\n\n\n “How complex is each record, and how many records remain in memory?”<\/strong><\/p>\n\n\n\n This approach gives a clearer view of the real memory requirement.<\/p>\n\n\n\n The term “memory leak” can describe several types of memory problems.<\/p>\n\n\n\n A traditional memory leak occurs when an application keeps memory that it no longer needs. The application cannot reclaim that memory because unwanted references still exist.<\/p>\n\n\n\n Pega applications can experience a different problem: uncontrolled data retention<\/strong>.<\/p>\n\n\n\n Consider this flow:<\/p>\n\n\n\n The Page List continues to grow because each processed page remains referenced.<\/p>\n\n\n\n The application is doing what the design tells it to do. However, the design keeps data that the process no longer needs.<\/p>\n\n\n\n That creates an architectural problem:<\/p>\n\n\n\n The application retains information beyond its useful lifetime.<\/strong><\/p>\n\n\n\n Increasing JVM heap size may delay the failure. However, it does not remove the underlying cause.<\/p>\n\n\n\n One common design problem is retrieving more data than the process needs.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n If the application can filter the data before it reaches the Clipboard, that approach is usually more efficient.<\/p>\n\n\n\n Instead of:<\/p>\n\n\n\n prefer:<\/p>\n\n\n\n This reduces the working set.<\/p>\n\n\n\n It also reduces unnecessary data transfer.<\/p>\n\n\n\n Another problem occurs when an application adds every processed record to a Page List.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n If the application never uses the final Page List, the stored records provide little value.<\/p>\n\n\n\n A better design is:<\/p>\n\n\n\n The application should retain only the information needed for the current task.<\/p>\n\n\n\n Copying complete pages can also increase memory use.<\/p>\n\n\n\n Suppose an API returns:<\/p>\n\n\n\n However, the application only needs:<\/p>\n\n\n\n Copying the complete response creates unnecessary duplication.<\/p>\n\n\n\n Instead, create a smaller structure that contains only the required properties.<\/p>\n\n\n\n This practice is especially useful in integration-heavy and batch-processing applications.<\/p>\n\n\n\n Data Pages provide convenient access to reusable data. However, developers should still consider data size and lifetime.<\/p>\n\n\n\n A potentially inefficient flow can look like this:<\/p>\n\n\n\n Data Pages are not automatically inefficient.<\/p>\n\n\n\n The key concern is how the application consumes the returned data<\/strong>.<\/p>\n\n\n\n Before copying or retaining Data Page content, ask:<\/p>\n\n\n\n The same principle applies to REST and other integration responses.<\/p>\n\n\n\n For example, an external service may return a large payload while the application needs only a few fields.<\/p>\n\n\n\n Keeping the entire response throughout a long-running process can increase the Clipboard working set.<\/p>\n\n\n\n Therefore, process only the data that the application actually needs.<\/p>\n\n\n\n Clipboard problems can remain hidden during development.<\/p>\n\n\n\n A developer may test an application with:<\/p>\n\n\n\n The application may perform well.<\/p>\n\n\n\n Production, however, may process:<\/p>\n\n\n\n or even millions of records.<\/p>\n\n\n\n The same logic now has a very different resource requirement.<\/p>\n\n\n\n A useful architectural model is:<\/p>\n\n\n\n Working Set \u2248 Number of Retained Objects \u00d7 Object Complexity<\/strong><\/p>\n\n\n\n This is not an exact JVM memory formula.<\/p>\n\n\n\n Instead, it provides a simple way to think about Clipboard growth.<\/p>\n\n\n\n If the number of retained objects keeps increasing, memory pressure can increase as well.<\/p>\n\n\n\n Typical symptoms include:<\/p>\n\n\n\n One useful warning sign is a gradual slowdown.<\/p>\n\n\n\n For example, the first part of a process may run quickly. Later, each batch may take longer.<\/p>\n\n\n\n When that happens, investigate data accumulation and working-set growth.<\/p>\n\n\n\n A structured investigation works better than simply increasing memory allocation.<\/p>\n\n\n\n First, determine where the problem occurs.<\/p>\n\n\n\n Possible areas include:<\/p>\n\n\n\n Knowing the processing path helps narrow the investigation.<\/p>\n\n\n\n Next, look for unusually large structures.<\/p>\n\n\n\n Pay attention to:<\/p>\n\n\n\n Then ask:<\/p>\n\n\n\n “Why is this data still present?”<\/strong><\/p>\n\n\n\n If the reason is unclear, investigate the structure further.<\/p>\n\n\n\n Review the rules involved in the processing path.<\/p>\n\n\n\n These may include:<\/p>\n\n\n\n Look for repeated page creation and unnecessary copying.<\/p>\n\n\n\n PDC and other platform monitoring capabilities can help identify performance patterns.<\/p>\n\n\n\n However, an alert does not automatically identify the root cause.<\/p>\n\n\n\n Instead, compare the findings with:<\/p>\n\n\n\n The goal is to connect the application operation with the observed performance impact.<\/p>\n\n\n\n Consider a customer migration process that receives a large file.<\/p>\n\n\n\n An inefficient design may look like this:<\/p>\n\n\n\n In this design, one requestor handles a very large working set.<\/p>\n\n\n\n As processing continues, the working set may grow:<\/p>\n\n\n\n A better design divides the workload into controlled units:<\/p>\n\n\n\n The right batch size should come from performance testing and workload characteristics.<\/p>\n\n\n\n Avoid choosing an arbitrary number.<\/p>\n\n\n\n The goal is simple:<\/p>\n\n\n\n Keep the active working set under control.<\/strong><\/p>\n\n\n\n Long-running, high-volume operations do not always need to depend on one synchronous requestor.<\/p>\n\n\n\n For suitable workloads, asynchronous processing can provide a more scalable design.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n This approach can provide several benefits:<\/p>\n\n\n\n Pega provides multiple options for asynchronous processing.<\/p>\n\n\n\n The right option depends on factors such as workload size, transaction boundaries, retry needs, and application architecture.<\/p>\n\n\n\n Therefore, the key principle is not simply:<\/p>\n\n\n\n “Use asynchronous processing.”<\/strong><\/p>\n\n\n\n Instead:<\/p>\n\n\n\n “Choose a processing model that matches the volume and lifetime of the work.”<\/strong><\/p>\n\n\n\n Reduce the dataset as early as practical.<\/p>\n\n\n\n Avoid retrieving everything and filtering it later.<\/p>\n\n\n\n If the application needs only a few properties, do not duplicate an entire complex page.<\/p>\n\n\n\n Do not continuously append records unless the complete collection is genuinely required.<\/p>\n\n\n\n Temporary structures should have a clear purpose.<\/p>\n\n\n\n Remove unnecessary data from the active working set when the process no longer needs it.<\/p>\n\n\n\n Test with realistic:<\/p>\n\n\n\n A design that works with 100 records may not work with one million records.<\/p>\n\n\n\n The following patterns deserve attention during code reviews.<\/p>\n\n\n\n This can work for small collections.<\/p>\n\n\n\n However, it becomes risky when the collection represents a high-volume dataset.<\/p>\n\n\n\n This may seem convenient during development.<\/p>\n\n\n\n However, copying a large response is wasteful when the application needs only a few fields.<\/p>\n\n\n\n More memory can postpone failure.<\/p>\n\n\n\n However, it does not fix inefficient data retention.<\/p>\n\n\n\n Large, long-running operations can create unnecessarily large working sets.<\/p>\n\n\n\n Breaking the work into smaller units can provide better control.<\/p>\n\n\n\n Small datasets can hide scalability problems.<\/p>\n\n\n\n Therefore, production-like testing remains important.<\/p>\n\n\n\n Before deploying a high-volume Pega process, review these questions:<\/p>\n\n\n\n These checks should become part of the design and code-review process for high-volume applications.<\/p>\n\n\n\n Pega Clipboard performance problems rarely start with an obviously incorrect design.<\/p>\n\n\n\n Instead, they can begin with small decisions.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n “Let’s temporarily store this record.”<\/p>\n<\/blockquote>\n\n\n\n “Let’s copy this response.”<\/p>\n<\/blockquote>\n\n\n\n “Let’s add this item to the Page List.”<\/p>\n<\/blockquote>\n\n\n\n “We might need this data later.”<\/p>\n<\/blockquote>\n\n\n\n Each decision may appear harmless.<\/p>\n\n\n\n However, repeating the same decisions thousands of times can create a large working set.<\/p>\n\n\n\n The lesson is not to avoid Page Lists or Clipboard structures. They remain important parts of Pega application development.<\/p>\n\n\n\n The real goal is to control what the application stores, how much it stores, and how long it keeps that data<\/strong>.<\/p>\n\n\n\n A scalable Pega application should keep its runtime working set focused on the current unit of work.<\/p>\n\n\n\n Large datasets should be filtered early when possible. They can also be processed in manageable batches or handled through suitable asynchronous and persistence mechanisms.<\/p>\n\n\n\n Ultimately, one question should guide Clipboard design:<\/p>\n\n\n\n “Does the application really need to keep this data in memory right now?”<\/strong><\/p>\n\n\n\n If the answer is no, removing that data from the active working set can help protect application performance and scalability.<\/p>","protected":false},"excerpt":{"rendered":" Introduction Performance problems in Pega applications do not always come from slow database queries or poor integrations. Sometimes, the problem is much closer to the runtime. One common cause is excessive data stored on the Clipboard. The Pega Clipboard acts as runtime working memory during case processing. It can hold case data, embedded pages, Page […]<\/p>\n","protected":false},"author":2,"featured_media":6345,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-6344","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"yoast_head":"\n1. Understanding the Pega Clipboard<\/h2>\n\n\n\n
Case\n\u2502\n\u251c\u2500\u2500 Customer Information\n\u251c\u2500\u2500 Address\n\u251c\u2500\u2500 Contact Details\n\u251c\u2500\u2500 Documents()\n\u251c\u2500\u2500 RelatedItems()\n\u2514\u2500\u2500 ProcessingData\n<\/code><\/pre>\n\n\n\n2. Why Page Lists Can Become a Performance Problem<\/h2>\n\n\n\n
Customer\n |\n \u2514\u2500\u2500 Addresses()\n \u251c\u2500\u2500 Address 1\n \u251c\u2500\u2500 Address 2\n \u2514\u2500\u2500 Address 3\n<\/code><\/pre>\n\n\n\nInput File\n \u2193\nRead Records\n \u2193\nCreate Page List\n \u2193\nStore 500,000 Records\n \u2193\nProcess Records\n<\/code><\/pre>\n\n\n\n\n
3. The Hidden Impact of Nested Structures<\/h2>\n\n\n\n
Customers()\n\u2502\n\u251c\u2500\u2500 Customer 1\n\u2502 \u2514\u2500\u2500 Orders()\n\u2502 \u251c\u2500\u2500 Order 1\n\u2502 \u251c\u2500\u2500 Order 2\n\u2502 \u2514\u2500\u2500 Order 3\n\u2502\n\u251c\u2500\u2500 Customer 2\n\u2502 \u2514\u2500\u2500 Orders()\n\u2502 \u251c\u2500\u2500 Order 1\n\u2502 \u251c\u2500\u2500 Order 2\n\u2502 \u2514\u2500\u2500 Order 3\n\u2502\n\u2514\u2500\u2500 Customer 3\n \u2514\u2500\u2500 Orders()\n \u251c\u2500\u2500 Order 1\n \u251c\u2500\u2500 Order 2\n \u2514\u2500\u2500 Order 3\n<\/code><\/pre>\n\n\n\n4. Clipboard Growth Is Not Always a Traditional Memory Leak<\/h2>\n\n\n\n
Start Processing\n \u2193\nCreate Temporary Page\n \u2193\nAdd to Page List\n \u2193\nProcess Next Record\n \u2193\nCreate Another Page\n \u2193\nAdd to Page List\n \u2193\nContinue...\n<\/code><\/pre>\n\n\n\n5. Common Causes of Excessive Clipboard Usage<\/h2>\n\n\n\n
5.1 Loading More Data Than Required<\/h3>\n\n\n\n
Database\n \u2193\n100,000 Records\n \u2193\nClipboard\n \u2193\nApplication Needs 500 Records\n<\/code><\/pre>\n\n\n\nLoad Everything \u2192 Filter in Memory\n<\/code><\/pre>\n\n\n\nFilter at Source \u2192 Load Required Data \u2192 Process\n<\/code><\/pre>\n\n\n\n5.2 Continuously Growing Page Lists<\/h3>\n\n\n\n
For each record:\n Process record\n Add record to ProcessedRecords()\n<\/code><\/pre>\n\n\n\nRead Record\n \u2193\nProcess\n \u2193\nPersist Result\n \u2193\nMove to Next Record\n<\/code><\/pre>\n\n\n\n5.3 Copying Complete Pages<\/h3>\n\n\n\n
CustomerResponse\n\u251c\u2500\u2500 CustomerID\n\u251c\u2500\u2500 Name\n\u251c\u2500\u2500 Contact\n\u251c\u2500\u2500 Accounts()\n\u251c\u2500\u2500 Transactions()\n\u251c\u2500\u2500 Documents()\n\u251c\u2500\u2500 Preferences()\n\u2514\u2500\u2500 History()\n<\/code><\/pre>\n\n\n\nCustomerID\nName\nContact\n<\/code><\/pre>\n\n\n\n6. Data Pages and Integration Responses<\/h2>\n\n\n\n
Large Data Source\n \u2193\nLoad Large Dataset\n \u2193\nCopy Entire Result\n \u2193\nStore in Page List\n \u2193\nRepeat\n<\/code><\/pre>\n\n\n\n\n
7. Why the Problem Often Appears Only in Production<\/h2>\n\n\n\n
100 Records\n<\/code><\/pre>\n\n\n\n100,000 Records\n<\/code><\/pre>\n\n\n\n\n
8. How to Troubleshoot Clipboard Growth<\/h2>\n\n\n\n
Step 1: Identify the Processing Path<\/h3>\n\n\n\n
\n
Step 2: Inspect Clipboard Structures<\/h3>\n\n\n\n
\n
Step 3: Trace Where the Data Is Created<\/h3>\n\n\n\n
\n
Step 4: Correlate Performance Monitoring<\/h3>\n\n\n\n
\n
9. A Production Example<\/h2>\n\n\n\n
Large File\n \u2193\nLoad All Records\n \u2193\nCreate Customers()\n \u2193\nStore Entire Dataset\n \u2193\nValidate\n \u2193\nCall External API\n \u2193\nUpdate Records\n \u2193\nGenerate Output\n<\/code><\/pre>\n\n\n\nMore Records\n \u2193\nLarger Page List\n \u2193\nMore Memory Retained\n \u2193\nIncreased Memory Pressure\n \u2193\nMore GC Activity\n \u2193\nLonger Processing Time\n<\/code><\/pre>\n\n\n\nLarge File\n \u2193\nRead Batch\n \u2193\nValidate\n \u2193\nProcess\n \u2193\nPersist Results\n \u2193\nHandle Errors\n \u2193\nNext Batch\n<\/code><\/pre>\n\n\n\n10. When Asynchronous Processing Makes Sense<\/h2>\n\n\n\n
Input\n \u2193\nQueue\n \u2193\nWorker\n \u2193\nProcess Record \/ Batch\n \u2193\nPersist Result\n \u2193\nNext Work Item\n<\/code><\/pre>\n\n\n\n\n
11. Five Practical Design Rules<\/h2>\n\n\n\n
1. Load Only What You Need<\/h3>\n\n\n\n
2. Avoid Unnecessary Page Copies<\/h3>\n\n\n\n
3. Control Page List Growth<\/h3>\n\n\n\n
4. Keep Temporary Data Temporary<\/h3>\n\n\n\n
5. Design for Production Volume<\/h3>\n\n\n\n
\n
12. Clipboard Anti-Patterns<\/h2>\n\n\n\n
Anti-Pattern 1: “Store Everything in a Page List”<\/h3>\n\n\n\n
Anti-Pattern 2: “Copy the Entire API Response”<\/h3>\n\n\n\n
Anti-Pattern 3: “Increase the Heap”<\/h3>\n\n\n\n
Anti-Pattern 4: “Process Everything in One Request”<\/h3>\n\n\n\n
Anti-Pattern 5: “It Worked in Development”<\/h3>\n\n\n\n
13. Production Readiness Checklist<\/h2>\n\n\n\n
\n
Conclusion<\/h2>\n\n\n\n
\n
\n
\n
\n