Avoiding Performance Pitfalls: Configuring your inbox

Way back in November of 2006 at the annual CCC conference in Washington DC, I gave a product roadmap presentation that highlighted the fact that, with all the flexibility Extranet provides, there is an opportunity to make advanced configuration choices which have unexpected consequences.

The most common areas related to Performance issues are:

• Security policies
• Custom searches
• Project Listing components as inboxes in personal pages

A common approach for nearly all Click Commerce Extranet sites is to provide each user their own personal page which includes links to the research protocols that the user should be aware of. The inbox is displayed using the Project Listing component which provides several options for defining what will be displayed.

Projects from multiple project types can be listed all at once, the list can be filtered based upon the status of the project and even further by selecting one of several built-in filters, such as “only show projects I own.” Use of these built-in options allows you to benefit from years of performance optimizations. It is often the case, however, that these options alone aren’t enough to meet your specific business rules. In this case, the component also provides a script hook that allows you to implement your own logic for generating the list of projects to display.

Scripts are a powerful way to extend and tailor the functionality of your site, but use of them also invites the opportunity for the introduction of performance issues. Within the Project Listing component, the script is provided some key information, including a set of projects which the component has built based upon the configured filtering options. The script can then further refine the projects set, define additional display columns and how the list is to be sorted. In special cases, for components configured to display projects from multiple projects types where additional filtering rules need to be implemented that depend upon custom attributes from one or more of those types, the prebuilt projects set cannot be used. Instead, a new projects set is built from scratch within the script.

All of this works quite well. Unfortunately, by ignoring the prebuilt set, we are asking the server to do work that is not leveraged. This work includes the selection of all selected project types, the filtering of those projects by state, and even more work to filter the list based upon security policies. To mitigate the performance impact of constructing the projects set which is ignored anyway, we need to configure the component options to do as little as possible. This is easily accomplished through the following steps:

1. Define a project type that is intentionally never used by the system so there are never any projects of that type. Configure the security policies for this new type to be as trivial as possible. Since there will be no projects of this type, there is nothing to secure anyway.
2. Select that “dummy” project type in the Filtering options
3. Do not select any States
4. Build your custom projects set in the script.

This technique avoids unnecessary processing and only makes the server perform work that is actually leveraged.

I encourage you to review your inbox configuration for all of your personal workspace templates. I wouldn’t be surprised if you discover opportunities to optimize.

Cheers!