Dashboard and Web Part Settings

You can modify settings to improve performance on a specific dashboard or Web Part.

General Guidelines

Ensuring that the Web Parts on your dashboards use caching properly will yield the biggest gain in dashboard performance. By using caching, you may avoid sending costly queries to the Web Storage System and running lengthy ASP-scripts to produce the dynamic output. Instead, the HTML or Extensible Markup Language (XML) content is retrieved straight from the cache and sent to the client. If you use caching properly, scalability in your dashboard site may increase significantly from handling hundreds of users to thousands of users.

Avoiding the Automatic Refresh for Dashboards

Dashboard refresh is turned off by default, as shown in Figure 15.3. However, it might have been turned on during configuration or the creation of sub-dashboards or personal dashboards. Avoid using the dashboard refresh feature that can automatically refresh itself after a specified number of seconds. This can create unnecessary traffic when users leave their browsers open and could put significant load on the server for no purpose.

Figure 15.3. Specifying the refresh rate

Using "All Users" Cache for Web Parts

Web Parts support caching on a per-user or per-dashboard basis. Specify the All Users cache setting when possible. This ensures that most requests to see this Web Part are read from the cache and the actual query is not executed. Even for Web Parts that show personal information, consider specifying a cache if the information it provides does not change frequently. These settings also apply to the standard Web Parts that are included with SharePoint Portal Server.

Increasing Refresh Time for Cache Time-outs

Each Web Part that uses a cache also has a setting specifying how often the cache should be refreshed. Take into consideration the type of information displayed in the Web Part and set the time-out value as high as possible. A high value means less traffic and reduced use of resources.

Additional Development Considerations

The type of search query that you conduct can also affect performance. Consider the following points when assessing query performance.

Avoid Doing DEEP TRAVERSALs on Per-User Web Parts

All the SharePoint Portal Server Web Parts perform queries against the Web Storage System. Some queries, like searching for all recently modified documents in the workspace or all documents checked out to the current user, are extremely costly due to performing a search across the entire Web Storage System and the results being cached only per user. Instead of putting this type of Web Part on the Home page of the dashboard site, consider putting it on a less frequently accessed page.

DEEP TRAVERSALs can work fine on the Home page if you are able to cache the Web Part for all dashboard users and the traversal is not extensive. For example, you should try to avoid doing a deep traversal of all document folders to list the five most recently published documents.

Use Persistent Search Folders

Instead of doing deep traversal or other cross-folder complex queries, use persistent search folders to implement this. This method is far more efficient and consumes fewer resources.