Share via

Tune Web server performance (Office SharePoint Server)

  • Article

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

In this article:

  • Architecture

  • Tuning

You can help improve the performance of Web servers by using the recommendations for physical architecture and tuning in this article.

Architecture

This section contains information about configuration, topology, and other aspects to consider for Web servers in a Microsoft Office SharePoint Server 2007 farm.

Use 64-bit servers for Web servers

We highly recommend that you install Web servers on 64-bit Office SharePoint Server 2007 on a 64-bit operating system, unless you have a significant business reason not to.

Carefully configure 32-bit servers

If you must run 32-bit Web servers, follow these recommendations:

  • Do not use the /3gb switch for 32-bit systems. If you are running 32-bit Web servers, we recommend that you do not use the /3gb switch in Windows Server 2003 to change the 2 gigabytes (GB) of virtual address space to 3 GB for all user mode processes. We recommend against using the /3gb switch because most SharePoint site traffic involves sending large amounts of data through the operating system. Therefore, leaving only 1 GB of address space for the operating system can destabilize the computer. For more information, see the following article in the Microsoft Knowledge Base: The Windows Server 2003 /3GB switch is not supported in Windows SharePoint Services 2.0 or in later versions or in SharePoint Portal Server 2003 SP2 or in later versions (https://go.microsoft.com/fwlink/?LinkId=105919&clcid=0x409).

  • Mixing 32-bit and 64-bit servers can affect load balancing. You can run an environment that has some Web servers running the 32-bit version of Office SharePoint Server 2007 and others running the 64-bit version. However, there is a risk that the 32-bit Web servers might become overloaded if the network load balancer is configured to use a less-intelligent model such as round robin. We recommend that you configure the load balancer to manage distribution based on load.

    Additionally, deploying both 32-bit and 64-bit servers increases the maintenance overhead for the farm. This is because third-party applications, custom solutions, patches, and software updates for both architectures must be tracked and managed independently.

Do not use Web gardens

Web gardens are Internet Information Services (IIS) application pools that are supported by multiple worker processes. We recommend that you do not use Web gardens for enterprise content management sites. This is because Web gardens have negative effects on page output caching.

Consider additional resources for systems with many active workflows

In a system that has many active workflow instances, consider adding more RAM, more Web servers, and more resources for computers that are running SQL Server 2005.

Use dedicated Web servers for services that are not exposed to end-users

A dedicated Web server is a Web server that is not connected to the load balancer that is exposed to end-users. We recommend that you use dedicated Web servers to run any services that are expensive, such as the following:

  • Search indexing

  • Central Administration

  • Profiles

  • Excel Services

Turn on only the features you need

Office SharePoint Server 2007 offers many features. Resources will be more efficiently used if you only turn on the features relevant to users. For information about turning off features, see Working with Features (https://go.microsoft.com/fwlink/?LinkID=105337&clcid=0x409).

Use Kerberos authentication for farms with heavy usage

We recommend that you use Kerberos authentication for farms in which you serve many requests for a given time unit, if so doing meets other business needs. Kerberos authentication can return authentication request results quickly because it uses caching.

Note

You might experience a delay in the user authentication process when you run a resource-intensive server application on a domain member in Windows Server 2003. For more information, see Knowledge Base article 906736: You experience a delay in the user-authentication process when you run a high-volume server program on a domain member in Windows 2000 or Windows Server 2003 (https://support.microsoft.com/default.aspx?scid=kb;EN-US;906736).

Tuning

This section contains information about configuration, end-user training, maintenance, and other recommendations for optimizing an existing Office SharePoint Server 2007 farm.

Monitor SQL Server performance

It is best to monitor performance and capacity from the bottom of the stack to the top, because stress on the database server is likely to cause stress on Web servers. For example, if the server that is running SQL Server is taking significantly more time to respond to a request from a Web server, and the Web server is receiving requests from end-users at a typical rate, requests on the Web server begin to queue up. This behavior can eventually result in what seems to be poor Web server performance, but is instead related to the database server.

For Search Server 2008, make sure that you monitor SQL Server index fragmentation, and follow the SQL Server defragmentation guidelines for SharePoint Products and Technologies that are provided in the following Microsoft Knowledge Base article: How to defragment Windows SharePoint Services 3.0 databases and SharePoint Server 2007 databases (https://go.microsoft.com/fwlink/?LinkID=105588&clcid=0x409). Doing this can significantly improve Search times.

Apply the ASP.NET # Induced GC counter hotfix

When you run a Microsoft ASP.NET 2.0 Web application that is built on the Microsoft .NET Framework version 2.0, such as Office SharePoint Server 2007, the value of the # Induced GC performance counter increases very quickly. Additionally, CPU usage becomes high, and the computer performance decreases. To resolve this issue, apply the hotfix available in the following Knowledge Base article: FIX: The # Induced GC performance counter value increases quickly and CPU usage becomes high when you run an ASP .NET 2.0 Web application that is built on the .NET Framework 2.0 (https://go.microsoft.com/fwlink/?LinkId=105921&clcid=0x409).

Configure application pool recycling settings for better availability

Use the guidance in this section to tune your application pools for improved availability.

  • If you have multiple Web servers in your farm, be sure that the application pools are set to recycle at different times on each Web server.

  • Recycle IIS Web sites at different times to spread loads across all Web servers in the farm. If you need to recycle more than one application pool on a specific Web site at the same time, you should temporarily remove that Web server from the load balancer to avoid poor performance during the recycling process.

  • When you plan application pool recycling on 32-bit servers, consider the amount of memory used by each application pool and revise the frequency of recycling based on the amount of memory used. Application pools that use fewer memory resources will need fewer recycles than application pools that use more memory.

    Memory management of 64-bit servers is more effective than that of 32-bit servers. Nonetheless, we recommend that you schedule nightly recycle of application pools for 64-bit servers. This helps reduce the possibility of problems caused by fragmentation.

For more information about application pool recycling, see Overlapped Recycling And SharePoint: What Are The 64-bit Settings? (https://go.microsoft.com/fwlink/?LinkId=127018).

Monitor and manage 32-bit worker process recycling

By default, 2GB of virtual address space is allocated for each 32-bit Windows user mode process. Some of this address space must remain unused for dynamic allocations. Additionally, some operations in Office SharePoint Server require large blocks of contiguous address space to perform dynamic allocations. The longer a process runs, the more fragmented the address space becomes. Because of this, when the size of the Office SharePoint Server worker process exceeds 1.2 GB to 1.4 GB, the process begins to experience out-of-memory errors and other anomalous events. As the process continues to consume address space, the errors get worse, eventually causing termination by IIS.

Important

In a 64-bit environment, the default values for process recycling when running are generally sufficient. Therefore, we do not recommend that you change them.

To resolve this issue, we recommend that you set up the following processes on each 32-bit Web server.

  • Use IIS overlapped recycling

    Regularly restarting the worker process can help reduce the fragmentation in the address space. This makes the process more robust and efficient. The overlapped recycling feature in IIS can be used to recycle the SharePoint worker process gracefully. This gives existing user requests time to be completed. Prior to stopping and restarting the existing process, a new process is started that takes all new requests. The old process is shut down when all existing requests are met or the shut-down time limit is exceeded.

    For best results, you should set IIS to recycle at specific times, and when memory usage reaches specific levels.

    • Configure a virtual memory-based recycle to occur at 1700 MB.

    • Configure the memory-used recycle to occur at 1000 MB.

    • Set the shutdown time limit to at least 300 seconds to give long-running user requests, such as large file uploads, an opportunity to be completed.

    • Use time-based recycles in environments that have regular heavy loads at certain periods of the day. Set a scheduled recycle about 30 minutes before the peak traffic starts.

    Failure to configure these settings on 32-bit servers might have an adverse effect on ASP.NET cache management. If you do not set a process memory limit, ASP.NET will calculate one for you. If the user mode address space is 2 GB, ASP.NET will use the lesser value of either 60% physical RAM or 800 MB. This value will be used to determine how aggressively the cache should clean up memory. Setting this value too low might result in too many memory cleanup operations. Setting it too high lets the process to grow too large and cause OutOfMemory exceptions and other errors.

    For more information about recycling worker processes, see Configuring Worker Processes for Recycling (https://go.microsoft.com/fwlink/?LinkId=105924&clcid=0x409).

  • Enable the LogEventOnRecycle IIS metabase property to track process recycling

    To track how often worker processes are recycling, you can use the LogEventOnRecycle property in the Internet Information Services (IIS) 6.0 metabase to generate entries in the system event log. If you find that these processes are recycling more frequently than every 4 hours, consider adding more Web servers to handle to the load.

    You can set the flags by using Adsutil.vbs. To write the causes of all application pool processes to the event log, follow these steps:

    1. Click Start, click Run, type cmd, and then press ENTER.

    2. Change to the directory where Adsutil is located. The following is the default directory location: %SYSTEMDRIVE%\Inetpub\AdminScripts

    3. Type the following command, and then press ENTER:

      cscript adsutil.vbs Set w3svc/AppPools/ <YourAppPoolName> /LogEventOnRecycle 255

      In this command, replace YourAppPoolName with the name of the application pool on which you want to enable the events.

      Note

      If the application pool name has a space in it, for example, “SharePoint- 80”, you must use double quotation marks around the metabase path in the command, as shown in the following example.
      cscript adsutil.vbs Set "w3svc/AppPools/SharePoint - 80/LogEventOnRecycle" 255

    For more information, see How to modify Application Pool Recycling events in IIS 6.0 (https://go.microsoft.com/fwlink/?LinkId=105925&clcid=0x409).

Perform maintenance during off-peak hours

Moving or deleting a site while other sites are being used can make the whole portal unresponsive. Therefore, perform these kinds of resource-intensive maintenance activities during off-peak hours.

Do not leave pages checked out

If you are using Enterprise Content Management, do not leave pages checked out. Instead, if it is possible, check them in quickly after every change. Leaving pages checked out reduces the performance of page rendering.

Carefully monitor use of customizations and Web Parts

Only deploy customizations that follow the best practices described in the following resources:

Also, monitor Web Parts and page rendering times. The Colleagues Web Part can be processing intensive. Do not use it on pages that display lots of other information.

Monitor and manage large files

While handling files larger than 5 MB, change the maximum upload size for documents to be the size of the largest expected file for your business needs. The default maximum upload size for files is 50 MB. The maximum file size supported by SharePoint Products and Technologies is 2 GB.

If there is a collection of large files that end-users often access, and if these files are updated infrequently, we recommend that you store them outside Office SharePoint Server. Instead, consider using an offline collaboration client.

Train end-users to work with large files

The way that end-users work with large files can have a significant effect on performance.

  • All end-users should have at least 50 MB allocated for temporary Internet files (the Internet Explorer cache), and should allocate more space if they regularly open large files. End-users that do not have space allocated for temporary Internet files generate significant load on Web servers.

  • End-users who work with documents larger than 25 MB should save the documents to their local computers. Opening large documents directly from a document library consumes bandwidth and resources while the document is open, and might automatically save changes directly to the document in the document library.

    End-users should right-click the document and save it to their computers before they open the document, and then upload any changes to the document library when they have completed their edits.

  • End-users should not use Explorer view to view large documents. Instead, they should use the All Documents view. When you open a SharePoint document library in Explorer view, placing the pointer over any of the enumerated files requests metadata for all of the files in the folder that you are browsing. In some cases, this might request the whole file. This can result in very high load on the server if many large files are simultaneously browsed in Explorer view.

  • End-users should not use the Download a Copy item on the Send To submenu on the Edit menu in the document libraries. The Download a Copy option opens the full file in the memory of the Web server.

Train end-users to work with large document libraries

The way that end-users work with large document libraries can have a significant effect on performance.

  • End-users should use customized view filters that have been indexed to work with large document libraries, and not access the libraries directly.

  • Encourage end-users not to use Explorer view to view large document libraries. Instead, they should use the All Documents view. When you open a SharePoint document library in Explorer view, placing the pointer over any of the enumerated files requests metadata for all of the files in the folder that you are browsing. In some cases, this might request the whole file. In folders that contain lots of items, this process can take a long time and might affect the performance of the server farm.

  • Work with end-users to create appropriate views for their needs, and discourage them from creating their own views for large lists. If you have a Web application that contains many large lists, you might consider disabling the Manage Personal Views permission for the whole Web application.

Manage large lists for performance

SharePoint Products and Technologies support large lists. However, you must carefully control how end-users view the lists to help prevent adverse effects on performance.

  • For best performance, do not exceed 2,000 items in a list level (for example, the root of the list or a single folder).

  • If you must create and browse large lists, use the following best practices:

    • Index the list on one or more columns.

    • Change the default view of the list to a customized filtered view that follows these recommendations:

      • The view returns fewer than 5,000 items.

      • The first column that you use to filter the view has an index and that it sufficiently reduces the total number of items returned.

      • The view displays only those columns that are absolutely required.

      • The view includes as few lookup columns as possible. Each lookup column in a list that is included in a view causes an additional join and additional calls to the database.

  • Evaluate list size with regard to the number of columns in a list. Lists with lots of columns can perform slowly.

Be aware that the following settings and operations can significantly affect the performance of a site that has large lists.

  • Complex explicit permissions (permissions on the list or library, folder, or item or document level) force authorization checking on each item.

  • Changing authorization settings.

  • Creating, updating, and deleting indexes.

  • Importing and exporting content.

  • Deleting a list.

  • Deploying new content types or updating existing content types.

If you have workflows that generate lots of task and history items, you might be creating large lists. For very active workflows, follow these practices:

  • Keep the AutoCleanupDays timer job running to clean up tasks on completed workflows older than 60 days.

  • When you create workflow associations, if you expect that a workflow will be heavily used or will create lots of task and history items, use non-default task and history lists.

Be aware that if you have a site that uses large lists, it can slow down the performance of site collection backups performed with the Stsadm backup operations.

If you plan to, or currently have very large lists, we strongly recommend that you read the following resources:

Download this book

This topic is included in the following downloadable book for easier reading and printing:

See the full list of available books at Downloadable content for Office SharePoint Server 2007.