While working on a large scale enterprise application, we want to utilize Data Pages to the maximum in a positive approach.
However if the count of the data pages is too high the size of the clipboard also increases. Eg: If there are 50 data pages which fetch 1000 records for each data page and cache on clipboard, the size is high. This might lead to performance issues.
Do we have any standard/ gaurdrail to say that we need to have XXX no of data pages in a application.
We don't have a recommendation on the number of concurrent data pages in an application since that number would depend on the size of each page. We do have a user-configurable limit of 1000 instances. The same scale planning and testing processess that one would apply to regular top-level pages should be applied to data pages. From a memory perspective, the biggest advantage to data pages is that there are a lot of configurable options to help control how the system behaves: https://docs-previous.pega.com/pega-7-management-data-pages
Posted: 8 years ago
Posted: 29 Apr 2015 8:07 EDT
Samanth Reddy chintakuntla (SamanthReddyc6298)
I have learnt that the size of the data pages is configurable (this is provided in detailed in pega help.) However I am still looking for more information say, if the number of datapages say 100-200(considering my application is big and using the data pages extensively) the size of the clipboard is going to increase in a big way. Do we have any recommendations in that area. Basically I am trying to think if the size of the data pages is higher than the user pages. How should we handle this sitaution. Please suggest.
Posted: 8 years ago
Posted: 29 Apr 2015 8:26 EDT
Kalim Saliba (SALIK)
Vice President, Product Engineering, Platform Technology
Converting an application from using regular top-level pages to using data pages should not result in increased memory usage. If anything, it should result in a decrease for a few reasons:
1. Using data pages results in better application design, since the structures, lifecycle, and caching of the data are all defined up front and only loaded on-demand. I've seen applications go from many redundant top-level pages to only a handful of data pages that accomplish the same tasks.
2. The system automatically prunes and passivates data pages.
3. I would not anticipate more data pages than user-pages if your use cases still call for the creation of the same top-level objects, which you'll be replacing -- not augmenting --- with data pages.
The single biggest option that will affect memory usage when it comes to data pages is the "limit to a single data page" checkbox on the data page form. If you don't need to cache multiple instances of the same page, you should definitely check this option.