Clarity PPM

CA PPM Partitions and Performance

By Aurora_Gaimon posted 12-13-2016 05:15 AM


Recently I had the opportunity to visit a customer with many partitions and performance issues. One of the questions I had is: “What is the maximum number of partitions within the same CA PPM instance?”


  • CA PPM documentation does not provide a specific number…
  • CA support advices as a good practice no more than 3…
  • On the other hand, the tool does not really limit you on 3…


So, what is the right answer? From my point of view, there is not a concrete number. It will depend on what you have configured “inside” the partition.


Key elements to be considerate:



  • Ensure right CA PPM sizing for your environment.
  • Monitor Database performance. Engage your DBA team.
  • Monitor CA PPM java memory usage (it should not go higher than 80%). You can easily check via URL:


or if SSL:


Refresh several times web browser to observer the peaks (if any).


Application Studio Configuration:

One of the key elements to bear in mind is studio views configurations. This will drag most of your front-end memory and performance.


  • Do not abuse of custom attributes per object: Best practices is no more than 100 and technical limitation of the tool is 500.
  • Do not abuse of display conditions (Sub pages): Best practices is no more than 10 per view. Tool does not provide specific technical limitation.
  • Use wisely the AVP (Attribute Value Protection) settings for portlets list views.

  • Ensure if you are willing to allow users to configure portlet list. Some users will add any possible attribute they see and use CA PPM as a dumping data too. Best practices is 20-25 columns (when no attachments, URL, images) or 10-15 columns when using expensive attributes.

  • Ensure "Rows per Page" is 20:

  • We recommend to use “Do not show results until I filter” to enhance navigation from portlet page to another:

  • Do not use same data provider (especially if it’s an out of the box with many custom attributes) to build all your portlet variation: NSQL queries should be built as data providers.



But again, this is not rocket since and it requires always an analyses per customer environment and business needs.


From my point of view, any page taking more than 3-4 seconds to display, it could be considerate slow and a performance issue. But!!! (there is always a but) heavily configured environments or pages could 5-6 seconds and accepted as a good performance from user perspective point of view.



That’s all. Thanks for reading until here. Did you like it? Please, don’t be shy and share it.




11-28-2017 10:30 AM

Yes, good information here Aurora. Thanks for sharing.

12-13-2016 05:35 AM

Thank you for sharing this, Aurora