Best Practices on Clarity Performance with large portlet(s) added to the view

Products

• Clarity PPM On Premise
• Clarity PPM SaaS

Issue/Introduction

Users are seeing slow performance connecting / trying to navigate to the overview/home page or another Clarity page (including custom pages or tabs). Portlets are spinning or there is a timeout error.

What are best practices to avoid this issue? 

Environment

Release: All Supported Releases

Cause

This is working as expected if any of the following apply:

1. The portlets contain a large amount of data.
2. If there are multiple large portlets are on the same page this can slow things down even more
3. The portlets contain more than 10-15 columns.

Notes:

• Portlets should not be used as a replacement for proper reports.
• The Clarity Studio Guide describes the Architectural Design and Intent of a portlet, in summary:

1. 1. Portlets are snapshots into Clarity data and can consist of grids, graphs, or snippets of HTML.
   2. While portlets do not replace Clarity reports, they can be regarded as mini-reports.
   3. You can create and publish portals across the enterprise.  Each portal page is comprised of a set of portlets – small windows of information presented as graphs, tables or web page snippets.

Resolution

Best practices on creating portlets:

1.  When utilizing aggregation over many rows of data, it is a best practice to create a separate summary portlet (e.g., one line portlet with totals.) 
   • A summary portlet allows the aggregation to be done on the database instead of returning all rows to the grid portlet to calculate the aggregation.
   • Page level filters provide for this capability. Filter on the page, which will give you a summary portlet along with detailed rows with no summarization.
2.  Set “Don’t show results until I filter” on portlets.
   • If there is a business requirement that requires data to be shown when the page is first accessed, than a default filter can be set to limit the result set.
3. We recommend portlets be avoided on the home page, or designed properly to allow quick end user access.
   • Use a different tab to add many portlets in order to ensure a quick login.
   • A poorly designed filter (or no filter at all) may launch a query returning all rows in the database while the end user is trying to login. 
   • This time needed to execute a poorly filtered or poorly optimized query can prevent the end user from accessing their home page and look like a “system down” condition.
4. Minimize the amount of columns to return via your portlet. 
   • Clarity has the ability to return as many columns as you want but there can be a performance impact for doing this. 
   • Do not use portlets as an “ad-hoc” vehicle, (selecting many columns into the query that are not displayed, in case the user wants to add columns to their grid later. This type of activity is should be managed in Jaspersoft Reporting. 
   • It's recommended to limit the amount of columns returned to 10-15 at the most
5. Make sure you restrict the use of the “configure” option on portlets on users’ home pages to further restrict the number of columns that can be displayed.
6. For custom portlets or queries, it's recommended to aim for average execution time under a maximum of 30 sec. If a custom portlet takes over 30 sec min, we recommend to redesign it and set required filters to avoid it from being ran wide open and take over this amount of time
7. Broadcom Support cannot help tune a custom NSQL query portlet if it's inefficient as this is outside of Support scope. A partner or consultant has to be engaged to perform the performance analysis and improve the NSQL query. If a custom portlet is deemed inefficient and causes performance slowdowns, it may be suggested for it to removed from the views before the fixes have been applied