Optimizing Performance of Microsoft SharePoint Portal Server 2001

Published: June 1, 2001

On This Page

Introduction
Stress Testing the Server
Monitoring Performance and Bottlenecks
Choosing the Right Hardware
Tuning the Web Storage System
Tuning for Dashboard Site Performance
Tuning Internet Information Server
Tuning Dashboard and Web Part Settings
Additional Resources

Introduction

Microsoft® SharePoint™ Portal Server 2001 is a flexible portal solution that integrates document management and search functions with the Microsoft applications and tools you use every day. SharePoint Portal Server extends the capabilities of Microsoft Windows®, Microsoft Office 2000, and Microsoft Office XP by offering knowledge workers a powerful new way to organize, find, and share information. For system architects and developers, SharePoint Portal Server is a solution that delivers dramatic new value by combining the ability to easily create corporate portals with document management and enterprise content crawling.

This white paper describes steps for tuning Microsoft® SharePoint™ Portal Server 2001. There are four areas that you can tune to optimize the performance and increase the scalability of the application:

• Microsoft Web Storage System

• SharePoint Portal Server settings

• Internet Information Server (IIS) settings

• Dashboard and Web Part settings

For best results, it is also important to use the appropriate hardware for your deployment goals.

Stress Testing the Server

When tuning an application it is important to be able to put stress on the server to identify bottlenecks and possible areas for improvement. You can use any tool to put stress on the server. The Microsoft Web Application Stress (WAS) tool lets you create or record a script that can used to put stress on a server. This application is free of charge and is available for download at https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx.

Monitoring Performance and Bottlenecks

Finding bottlenecks is the key to improving application performance and scalability. Monitoring performance counters is an important part of this process. The most important performance counters to monitor for SharePoint Portal Server are:

• Processor — % Processor Time.

  Note: SharePoint Portal Server performance is usually bound by the speed of the CPU so watch this counter closely when putting load on the server. If the CPU spikes consistently, you may need to upgrade your hardware, implement tuning that may reduce the CPU load caching, or move CPU intensive tasks to another server.

• Memory — % Committed bytes in use

• Active Server Pages — ASP Request Execution Time

• Active Server Pages — ASP Request Wait Time

• Active Server Pages — ASP Requests Queued

You can use Performance Monitor to collect data from these counters, or you can use WAS to collect data while performing a stress test.

Choosing the Right Hardware

Selecting an appropriate server platform is an extremely important component of a successful portal deployment. The key hardware requirements are the CPU speed, amount of RAM, and hard disk space:

• Increased CPU resources allow SharePoint Portal Server to provide an excellent user experience to large numbers of users during peak usage periods.

• If there are insufficient CPU resources, users experience unacceptable server response times during peak usage periods.

• Additional RAM and hard disk space allow SharePoint Portal Server to provide improved user performance.

• If there is insufficient RAM, users experience unacceptable server response times regardless of the number of active users.

• If there is insufficient hard disk space, users are not able to search for or save additional documents.

An important step in determining your server hardware requirements is establishing clear performance and scalability requirements. For more information about determining your hardware requirements, see the "Capacity Planning" white paper at https://www.microsoft.com/sharepoint.

For the purposes of this paper, use the following guidelines:

Enterprise Portal Deployment

For such a deployment, the following characteristics are reasonable:

Characteristics

• Primarily browse and search activity

• 10,000 users

• 10 authors, 10,000 readers

• 2,000,000 or more indexed documents

Hardware

• Quad processor 700 MHz Pentium III with 2 GB of RAM, 100 GB hard disk drive (3 spindles)

• A large search site benefits from using a server dedicated to crawling content to improve performance for users of the server dedicated to searching.

Business Unit Portal Deployment

Characteristics

• Some document management but still a high volume of browse and search activity

• 500-2,000 users

• All author rights

• Multiple workspaces

• 10,000 documents stored, 100,000-200,000 indexed.

Hardware

• Quad processor 700 MHz Pentium III with 2 GB of RAM, 100 GB hard disk drive (3 spindles)

Workgroup Portal Deployment

Characteristics

• Document management activities equivalent to browse and search activities

• Fewer than 200 users

• Equal number of authors and readers

• 100,000 indexed documents

Hardware

• Single processor 500 MHz Pentium III with 512 megabytes (MB) of RAM, 20 GB hard disk drive.

Tuning the Web Storage System

The Web Storage System database and the Store.exe process are at the heart of the SharePoint Portal Server application. They provide the data for the dashboard site itself and the content in the various Web Parts on the dashboards. There is very little manual tuning that can be completed due to improvements in the store.exe auto-tuning capabilities. However, some settings can be modified and may improve dashboard site performance.

For the Web Storage System included with SharePoint Portal Server, these settings are stored in the registry under

HKEY_LOCAL_MACHINE \Software \Microsoft \ESE98 \Process
Information Store\System Parameter Overrides\

Extensible Storage Engine Heaps

When SharePoint Portal Server is installed on servers with more than four processors, you may notice high virtual memory usage by the Extensible Storage Engine (ESE) multi-heap. High virtual memory usage can lead to performance problems, especially when the server has multiple gigabytes of memory. Although ESE multi-heaps relate specifically to Exchange 2000 servers that have many databases and storage groups configured, tuning this setting may also benefit computers running SharePoint Portal Server. It is recommended that you add the following registry parameter to all servers with more than four processors:

Note: You must restart the Exchange Information Store process after the previous registry parameter is adjusted.

MaxSession Settings

The default number of available database sessions is 40. When running a lot of activities (backups, user sessions, subscription notifications, indexing, etc.) against the server, you can easily run out of database sessions. In this case, you can modify the following registry parameter:

Log Buffers

Web Storage System uses log buffers to store information in memory before writing to the transaction logs. For SharePoint Portal Server, the default value is 84. This value might be too low and could be the cause of excessive disk I/Os to the transaction log drive. Significant performance degradation is seen if the server is under load or if users are sending large messages. The default value should be increased to 9000 on all servers.

Store Database Cache Size

Exchange 2000 ships with a hard-coded maximum store database cache size of 900 MB. SharePoint Portal Server computers with more than 1 GB memory may benefit from an increase in the size of this cache. Because of virtual address space limitations, this value should never be set higher than 1,200 MB.

Note: The 900 MB limit is in place to ensure that the Store.exe process always has ample virtual address (memory) from which to allocate. Increasing this value too much can lead to system instability. For more information about virtual address space, see Microsoft Knowledge Base (KB) article 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM."

There are many factors that can affect the virtual address space size in the Store.exe process. Some of these factors are:

• Initial allocation of virtual address space on startup

• Number of threads running

• Size of the store database cache

• Number of storage groups and databases on the server (this factor does not affect SharePoint Portal Server computers)

Before increasing the maximum cache size, it is recommended that the administrator use Microsoft Windows® 2000 Performance Monitor to monitor the server memory under normal load.

Monitor the following Performance Monitor values:

• Performance Object: Process

• Counter: Virtual Bytes

• Instance: STORE

The information gathered from Performance Monitor gives you an accurate value for the virtual address space that the Store.exe process allocates. On a server with the /3GB switch set in the Boot.ini file, the value seen in Performance Monitor should be below 2.8 GB. On a server without the /3GB switch set in the Boot.ini file, the value should be below 1.8 GB. It is recommended that servers with 1 GB or more of memory have the /3GB switch added to Boot.ini file. If you see values that are higher than those for either configuration, do not increase the size of your maximum cache size. If you see values that are lower for either configuration, you can safely increase the size of your database maximum cache size. For example, if you have a server configured with the /3GB switch, and performance monitor shows the virtual bytes count at 2.5 GB under heavy load, you know you can safely increase your maximum cache size by 300 MB, for a total of 1,200 MB.

Tuning for Dashboard Site Performance

Use Index Workspaces for Indexing on a Separate Server

When possible, use a separate server with an index workspace to perform all the indexing tasks. Because creating and updating an index is a resource-intensive process, you can choose to have a separate server that is dedicated to creating and updating indexes. The workspace on this server is an index workspace. An index workspace is designed to manage only content sources. The index workspace does not use the document management capabilities of SharePoint Portal Server, such as checking in or checking out documents or versioning, nor does it provide a dashboard site.

Adjust Indexing and Search Resource Usage

On the computer hosting the dashboard site, adjust the resource usage of the server to "background." To do this, open Microsoft Management Console, right-click the SharePoint Portal Server computer name, select Properties, and then click the General tab. Adjust the Search resource usage and Indexing resource usage settings to Background. This will ensure that no background indexing tasks consume CPU resources and take away resources from the dashboard site and the Web Storage System. However, if your workspace is used for many search activities, you may want to adjust the Search resource usage to Dedicated instead.

Move Property Store Files to a Different Volume

For high performance, the property store and property store log files must be on separate dedicated physical volumes. You cannot move property store files by using Microsoft Management Console. You must use catutil.exe to move property store files and to change the location of property store log files.

SharePoint Portal Server provides a utility named catutil.exe that you can use to move index files and property store files and to change the location of property store log files. Property store files contain the metadata from documents. The property store log files are the log files for the property store. These files are shared across all workspaces on a server. By default, the property store file and property store log files are stored in the SharePoint Portal Server \Data\FTData\SharePointPortalServer directory.

To move the property store file to a new location:

1. Stop the Microsoft Search Service (MSSearch).

2. On the Start menu, point to Programs, point to Accessories, and then click Command Prompt.

3. Change to the Program Files\Common Files\Microsoft Shared\MSSearch\Bin directory.

   Note: By default, catutil.exe is stored in the Program Files\Common Files\Microsoft Shared\MSSearch\Bin directory. However, if you install SharePoint Portal Server on a computer running Microsoft SQL Server™ 7.0, SQL Server 2000, or Exchange 2000 Server Service Pack 1, catutil.exe is stored in the Program Files\Common Files\System\MSSearch\Bin directory.

4. At the command prompt, type catutil.exe PROPSTORE and then press ENTER. A usage description displays.

5. Type catutil.exe PROPSTORE SharePointPortalServer -m "<path>\sps.edb" and then press ENTER.

   For example, if you want to move the property store to a directory named Store on drive D, you would type catutil.exe PROPSTORE SharePointPortalServer -m "D:\Store\sps.edb"

   Note that you can change the name of the .edb file from sps.edb to something else. For example, you can type catutil.exe PROPSTORE SharePointPortalServer -m "D:\Store\MyFileName.edb"

6. Start the MSSearch service.

To specify a new location for the property store log file:

1. Stop the MSSearch service.

2. On the Start menu, point to Programs, point to Accessories, and then click Command Prompt.

3. Change to the Program Files\Common Files\Microsoft Shared\MSSearch\Bin directory.

   Note: By default, catutil.exe is stored in the Program Files\Common Files\Microsoft Shared\MSSearch\Bin directory. However, if you install SharePoint Portal Server on a computer running SQL Server 7.0, SQL Server 2000, or Exchange 2000 Server Service Pack 1, catutil.exe is stored in the Program Files\Common Files\System\MSSearch\Bin directory.

4. Type catutil.exe PROPSTORE and then press ENTER. A usage description displays.

5. Type catutil.exe PROPSTORE SharePointPortalServer -l <path> and then press ENTER.

   For example, if the property store file is on drive D, you may want to change the location of the property store log files to a directory named Logs on drive E to improve performance. You would type:

catutil.exe PROPSTORE SharePointPortalServer -l"E:\Log"

6. Start the MSSearch service.

   Important: Do not change the location of the property store log files to the root of a directory. For example, do not change the location to D:\. MSSearch does not function properly if the files are on a directory root. If you have changed the location to a directory root and search no longer functions, change the location of the files to a subdirectory instead. For example, change the location to D:\Log Files.

Improve Query Performance

This procedure is from the SharePoint Portal Server Readme file:

If query performance is slow and the computer has processor memory available, you can increase performance by specifying that MSSearch keep the property store in memory.

If query performance is slow and the computer has processor memory available, you can increase performance by specifying that MSSearch use it to keep the property store in memory.

To increase query performance

1. On the taskbar, click Start, and then click Run.

2. Type regedit and then click OK.

   Caution: Be careful when editing the registry. If there is an error in your registry, your computer may not function properly.

3. In Registry Editor, go to HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Search \1.0\Databases.

4. Right-click Databases, point to New, and then click DWORD Value. A new DWORD value appears.

5. Type CacheSizeMax as the name for the new value, and then press ENTER.

6. Right-click CacheSizeMax, and then click Modify. The Edit DWORD Value dialog box appears.

7. In Value data, type the maximum number of 4,096 byte pages that you want the server to keep in memory. For example, if you want to use 1 GB of RAM, divide 1,024(3) (1,024 multiplied by 1,024 multiplied by 1,024) by 4,096, and enter 262,144 in Value data.

   Important: The total address space for MSSearch is 2 GB. Do not enter a value greater than 1.7 GB, even if you have 2 GB or more of RAM.

8. In Base, click Decimal.

9. Click OK.

10. Right-click Databases, point to New, and then click DWORD Value. A new DWORD value appears.

11. Type CacheSizeMin as the name for the new value, and then press ENTER.

12. Right-click CacheSizeMin, and then click Modify. The Edit DWORD Value dialog box appears.

13. In Value data, type the minimum number of 4,096 byte pages that you want the server to keep in memory. This number should be between 50 and 90 percent of CacheSizeMax. For example, if CacheSizeMax is 262144, enter a number between 131072 and 235929 in Value data for CacheSizeMin.

14. In Base, click Decimal.

15. Click OK.

16. Close Registry Editor.

    Restart MSSearch. To do this:

    • On the taskbar, click Start, point to Programs, point to Administrative Tools, and then click Services.

    • Right-click Microsoft Search, and then click Restart.

Tuning Internet Information Server

Both SharePoint Portal Server and the Web Storage System are exposed and accessed through IIS. Because all traffic, whether from the client using the Web Folder shell or from the browser, goes over Hypertext Transfer Protocol (HTTP) and IIS, it is important that IIS be tuned properly to avoid becoming a bottleneck.

This section contains some general guidelines for tuning IIS for the dashboard site.

Run the ASP Engine In-Process

By default, IIS runs with medium application protection. This means that the ASP-engine is pooled and the ASP-applications are using the ASP-engine running outside of the IIS process. This requires significant performance overhead to marshal data and security contexts between processes. To set the ASP-engine to run in process with the IIS process, right-click the default Web site in the Internet Services Manager, click properties, and then click the Home Directory tab. Change the Application Protection setting from Medium (Pooled) to Low (IIS Process).

Caution: This modification makes it possible for malfunctioning Web Parts or scripts to take down the entire IIS process. It is recommended that you configure recovery options for the World Wide Web Publishing service to ensure that the process restarts properly if a failure occurs.

Adjust the ASP Settings

The ASP-engine has several parameters that can be used to increase the performance and scalability of your dashboard site. The need to modify these parameters is determined by your hardware configuration and your assembled set of Web Parts. Closely observe the ASP Request Wait Time and ASP Requests Queued performance monitor counters to determine if there are any bottlenecks that can be removed by tuning the ASP-engine.

The following guidelines are taken from KB-article 253146.

AspProcessorThreadMax

The AspProcessorThreadMax metabase property specifies the maximum number of worker threads per processor that IIS creates. The setting can dramatically influence the scalability of your Web applications and the performance of your server in general. Because it defines the maximum number of ASP requests that can run simultaneously, this setting should remain at the default unless your ASP applications are making long-running calls to external components. By default, AspProcessorThreadMax is set to 25.

AspRequestQueueMax

The AspRequestQueueMax metabase property specifies the maximum number of concurrent ASP requests that are permitted into the queue. Any client browsers attempting to request ASP files when the queue is full are given an HTTP 500 "Server too busy" error message. By default, AspRequestQueueMax is set to 3,000.

AspQueueConnectionTestTime

IIS places all ASP requests into a queue. If the request has been queued for longer than the number of seconds specified by the AspQueueConnectionTestTime metabase property, ASP checks to determine whether the client is still connected before it executes the request. If the client is no longer connected, the request is not processed and is deleted from the queue. You can use the AspQueueConnectionTestTime metabase property to make sure that IIS does not waste time processing a request that has been abandoned by the user. By default, AspQueueConnectionTestTime is set to 3.

AspScriptEngineCacheMax

The AspScriptEngineCacheMax property specifies the maximum number of scripting engines that ASP pages will keep cached in memory. By default, AspScriptEngineCacheMax is set to 125.

AspSessionTimeOut

The AspSessionTimeOut property specifies the default amount of time (in minutes) that a session object is maintained after the last request associated with the object is made. AspSessionTimeOut can be used to tune your ASP applications. Because session objects consume some memory resources, limiting the lifetime of an individual session with this property makes your applications more scalable. By default, AspSessionTimeOut is set to 20.

Caution: Modifying the metabase incorrectly can cause serious problems that may require you to reinstall IIS 5.0. Microsoft cannot guarantee that problems resulting from incorrectly modifying the metabase can be resolved. Modify the metabase at your own risk.

Run the Adsutil.vbs utility from the <%SYSTEMDRIVE%>\inetpub\adminScripts directory. For example, to reconfigure the AspRequestQueueMax metabase property, type the following command:

adsutil.vbs set w3svc/AspRequestQueueMax <NewValue> 

Where <NewValue> is the number of requests that ASP should use per processor.

Note: For all entries, these settings change the value at the Master WWW Properties level, where they are inherited by all new Web applications and all existing applications that have not explicitly set a different value.

Tuning Dashboard and Web Part Settings

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.

Avoid Using the Automatic Refresh for Dashboards

Dashboard refresh is turned off by default. 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.

Use "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 ship with SharePoint Portal Server.

Increase Refresh Time for Cache Time-outs

Each Web Parts 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

Avoid Doing DEEP TRAVERSALs on Per-User Web Parts

All of the SharePoint Portal 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 them 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 is far more efficient and consumes fewer resources. For more information about how to create and use a persistent search folder, see the Web Storage System Software Development Kit (SDK).

Additional Resources

Exchange 2000 Internals: Quick Tuning Guide, Paul Bowden, Program Manager, Microsoft Exchange Server Product Unit, see https://www.microsoft.com/technet/prodtechnol/exchange/2000/maintain/exchtune.mspx for the latest information.

Tuning the Performance and Scalability of ASP Web Applications