Additional performance and capacity planning factors (Office SharePoint Server)
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
This section describes additional factors which you should consider when planning your deployment.
Environmental factors
Content Query Web Parts
Environmental factors
Network considerations
Network security
Authentication
Developing custom code
Network configuration
Network configuration is critical to the performance of your Office SharePoint Server or Windows SharePoint Services installation. Common network components which can affect your performance include:
Network Interface Card (NIC)
NIC settings Where possible, you should always use Gigabit network cards. If you have self-switching cards (100 MB / 1 GB), you should always set the over-ride to use 1 Gigabit.
Inbound/Outbound For scenarios where you expect high traffic, we recommend you have separate NICs to handle inbound and outbound traffic.
**Switches **If you run your network through a switch, ensure that you are using a GB switch and that you have the same number of inbound/outbound channels.
**Routers **Ensure your routers are configured on a GB infrastructure.
Domain controllers It is possible for authentication to become a performance bottleneck in your SharePoint environment if the domain controller (DC) receives requests more quickly than it can respond. For environments using user authentication such as NTLM, we recommend a ratio of 3 Web servers per DC. If your tests indicate that the authentication load at 3 Web servers per DC is acceptable, you can add one more Web server per DC for a supported limit of 4 Web servers per DC.
Keep in mind that network configuration should be planned and tested thoroughly prior to moving a system to a production environment.
Network topology recommendations
Plan your network connections within and between farms. We recommend that you use a network with low latency.
The following list provides some best practices and recommendations.
All servers in the farm should have LAN bandwidth and latency to the server running SQL Server 2005 (up to 1 millisecond (ms) latency).
We have not tested a deployment of Office SharePoint Server 2007 in which a server running SQL Server 2005 is deployed in a wide area network (WAN) topology remotely from other components of the farm with network latency greater than 1 ms. Therefore, we do not recommend such a WAN topology.
Plan for an adequate WAN network if you are planning to use SQL Server 2005 mirroring or SQL Server 2005 log shipping to keep a remote site up-to-date.
Network security
See Plan for secure communication within a server farm (Office SharePoint Server) for more information on network security.
Authentication
The authentication mechanism used in your environment has an incremental effect on the overall performance of the system. Factors which contribute to authentication performance include:
The number and speed of round trips to the authentication provider
Authentication provider processing performance
Microsoft tests indicate that the order of authentication mechanisms, from fastest to slowest, are as follows:
Anonymous
Kerberos
NTLM
Basic
Forms
If you choose to write an authentication provider to use with Office SharePoint Server or Windows SharePoint Services, you should follow the best practices guidelines in the MSDN article Authentication in ASP.NET: .NET Security Guidance (https://go.microsoft.com/fwlink/?LinkId=98743).
Developing custom code
The most common cause of poor performance in earlier releases of SharePoint Server is the development and deployment of inefficient custom features on top of the SharePoint platform. When developing customer features for SharePoint, there are a number of performance metrics you should monitor. These include, but are not limited to:
SQL Server round trips For core pages, we recommend no more than 2-3 SQL round trips. Excessive round trips have the following deleterious effect on performance:
Increased end user response time due to greater server-side processing time
Reduced overall system throughput due to additional load on the database server.
**SQL server CPU utilization **In order for your MOSS system to remain healthy, it is important that CPU utilization on the database server(s) remains relatively low. If SQL Server 2005 CPU usage averages more than 60%, performance will be adversely affected. Steps you can take to reduce SQL CPU utilization include:
Implement a caching strategy – this reduces the overall number of calls from the Web server(s) to the database server.
Optimize custom code to use object methods which return your desired data in the most efficient manner (e.g. introduce indexes on lists, etc.)
Distribute your SQL databases across multiple physical database servers
Page download size Keep code size to a minimum. A relatively small increase in page size can have a significant impact on performance if that page is accessed by a large number of people every day, especially during peak hours.
Client-side code efficiency Approximately 50% of end user response time is comprised of client side processing of returned code. If your custom solution increases any of these, you can expect an adverse effect on end user response time.
**AJAX callbacks **For AJAX parts, the number of callbacks, and the payload for each callback. For example, each KPI makes 3 calls in order to return the result. Make sure you test page performance when you introduce multiple KPIs or other custom code into a page.
Content Query Web Part
The Content Query Web Part utilizes the Windows SharePoint Services cross-list querying mechanism to retrieve content from a SharePoint site collection. If the Web Part is configured to issue a query that involves a large number of lists, the cross-list query mechanism may raise an exception.
By default, cross-list queries have a list limit of 1,000. This means that if you configure the Content Query Web Part with a query that includes more than 1,000 lists, the cross-list query will not complete, and the Web Part will not show any content. The reason for this throttling is to avoid overburdening SQL Server 2005.The more lists the cross-list query includes, the longer it takes for the database server to return the content the query is asking for. For very large numbers of lists, this could cause the database server to disproportionately process cross-list queries at the expense of other requests.
If your requirements involve querying for more than 1,000 lists, you can increase the list limit if the database load that the operations require is acceptable. You can do this by adding a MaxListLimit attribute to the ListsOverride property of the Web Part. For example, if you wanted to raise the list limit to 2000, you would set the ListsOverride property as:
<Lists ServerTemplate="850" MaxListLimit="2000">
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.