The previous section provides general recommendations for bandwidth ranges for regional sites based on the solution that is implemented. However, your organization’s specific bandwidth needs might vary based on the tradeoffs that you make in implementing a regional solution and your organization’s tolerance of lower-bandwidth behavior.

This section provides data intended to help you understand the impact of specific bandwidth measurements on the regional site solution. By using this data, you can estimate the specific bandwidth targets for your regional solution.

Regional User Experience

The regional user experience with a SharePoint Products and Technologies solution is gauged by how long the user waits for operations to complete. Bandwidth utilization of user actions falls into two categories based on the amount of data transferred over the WAN:

• Common user operations   Browsing through sites and viewing average-size pages
• Complex user operations   Uploading or downloading a document

The measurements in this section provide an estimate of how long users will wait for common and complex operations to complete. An asterix (*) in a cell indicates that that bandwidth range is not recommended for specific numbers of users due to the risks that are introduced by bandwidth saturation. For example, supporting 10,000 users over a 0.5 Mbps link is not recommended. For more information on the risks introduced by bandwidth saturation, see Risks of Bandwidth Saturation During Peak Load later in this section.

Methodology

The values in the previous two tables are determined by using the formulas presented later in this paper (see Calculating Bandwidth Requirements to Support Regional Users) and then calculating wait time by using the following formula:

(NetOps per Second × Network Cost of Common or Complex Operation × 8) ÷ 1024

Where NetOps per Second stands for Network Operations per Second.

This formula assumes that 10 percent of the network bandwidth is not available due to standard network overhead (10 percent overhead) and that 100 percent of remaining bandwidth is available (90 percent of the total bandwidth).

 Note   The user response times will be higher on links with very high latencies, such as trans-oceanic links. At this time, the formulas provided in this paper do not allow you to adjust latency as a variable.

Risks of Bandwidth Saturation During Peak Load

The data provided in this section estimates the amount of bandwidth necessary to support an acceptable user experience at a regional site. However, as you plan for and monitor your regional site, pay attention to the risk of bandwidth saturation and the resulting impact to your network and SharePoint Products and Technologies solution, especially during peak hours:

• Routers   When routers are presented with large amounts of data to send across a link, but no available bandwidth to send the data, the routers will quickly fill their buffers and start discarding packets. This will cause all communications across that link to break down quickly. For example, if you plan for a response time of one minute for a complex operation to complete, with 10,000 users over a 3 Mbps connection, the router might easily become overloaded and service can be disrupted.
• Users   When users start experiencing response times that are unusually higher than normal, such as during peak hours with an overloaded circuit, the natural response is to attempt to resend the request before the original request has completed. This behavior increases the bandwidth demand when the bandwidth is already saturated.
• Web server  Large numbers of incomplete requests can impact the performance of the front-end Web server as this server continues to use processing time and allocate memory to service requests that continue to time-out.

Given the risks of bandwidth saturation to your SharePoint Products and Technologies solution, ensure that you plan your bandwidth requirements to support users during peak hours.

Bandwidth Use in Crawling Content

If you decide to host Windows SharePoint Services sites or a full SharePoint Portal Server solution at the regional site (Solutions 2 and 3), you can optionally include the regional content in enterprise-wide search hosted by the central site. This involves configuring the central site to crawl the regional site content. Because of the high-bandwidth use of the crawl process, the key variables in determining if this is a viable or desirable option are:

• The volume of data to crawl.
• The amount of time required for the crawler at the central site to complete the crawl process at the regional site.

Understanding how these variables affect bandwidth use will also help you define parameters around how you configure the crawl process, such as when to crawl, how often to crawl, and whether to crawl all of the content or only a subset of the content. For example, in a low-bandwidth scenario, you can configure the crawler to crawl only high-priority content, once a week, and starting Friday evening with the goal of ending early Monday morning. You can also consider dedicating a separate WAN line to provide crawl functionality without affecting regional users. For more information about optimizing the crawl process, see Deployment and Configuration Related to Geographically Dispersed Sites Solutions later in this paper.

The crawl process uses all available bandwidth up to approximately 28 Mbps. After 28 Mbps, user-generated operations can be accommodated simultaneously but performance can be compromised. The following chart provides estimated times for crawling content based on the available bandwidth and the volume of data.

The data cells highlighted with bold numbers represent the WAN link and content size combinations that are more likely to support a typical overnight (10 to 12 hour window) target for crawling content. Cells with asterixes (*) represent WAN and content size combinations that are not recommended.

Methodology

The following formula was used to generate the data in the previous table.

Where:

• Total Bandwidth (bits) = Total Bandwidth (Mbps) X 1024 X 1024
• Available Bandwidth % = 100 – Overhead Factor / 100
• Overhead Factor = 10

This formula assumes that 10 percent of the network bandwidth is not available (10 percent overhead) and that 100 percent of remaining bandwidth is available (90 percent of the total bandwidth).

Total content crawled assumes that the indexing update type is set to Full Update. The total amount of content that is crawled can vary greatly if other index update options are configured. For more information, see the "Configuring Content Index Update Options" section in Optimizing Indexes for Crawling Regional Farm Content over the WAN.

 Note   The formula provided for estimating crawl time and the resulting data is based on a latency of 40 ms. At this time, the formulas provided in this paper do not allow you to adjust latency as a variable.

Additional Factors that Impact Crawl Times

The data in the Estimated Time to Crawl table is based on crawling one of the Microsoft internal content databases. The content database was selected because it contains a good blend of Web pages and documents and it includes documents of various sizes. You can adjust the formula to account for variables that impact crawling performance by increasing the value for Overhead Factor. Consider increasing this value for the following scenarios:

• Latencies greater than 80 ms
• Packet Loss greater than 1 percent