Distributing and Optimizing SharePoint Workload
Solving bandwidth and latency issues and improving the performance of a SharePoint implementation can lead to better experiences for users and lower costs for IT.
As Microsoft Office SharePoint Server has become more widely deployed to meet the collaboration and content management needs of organizations, it has become increasingly clear that IT professionals face some difficult operational challenges as their infrastructures grow. This is particularly true in organizations that have large numbers of users, often spread across the country or even around the world. The increasing importance of the SharePoint infrastructure and of the content to which it provides access involves stringent uptime requirements, usually in the form of service-level agreements (SLAs). In addition to providing a server infrastructure that's robust enough to meet uptime requirements, IT must also ensure that the user experience is consistent. Microsoft actually recommends your SharePoint infrastructure should only be deployed when bandwidth and latency between sites are capable of providing a reasonable user experience. In addition to meeting the technical requirements of a SharePoint deployment, there are other benefits to addressing issues associated with the user experience. By meeting users' expectations in terms of such issues as system responsiveness and document load time, it's possible to have a positive impact over all IT operations -- from the network team, which will not have to troubleshoot documents that take forever to download, to the help desk, which will not have to field calls about why SharePoint is so slow.
While providing a consistent experience has not traditionally been a challenge in a LAN environment, it's a different story as far as remote offices are concerned. The remote scenario is becoming more common as the push toward centralized IT continues. Often remote offices, particularly those with smaller numbers of users, have Wide Area Network (WAN) connections that are slow or overtaxed. Unfortunately, as SharePoint has become more important, IT has faced increasingly difficult challenges in providing a consistent user experience to every worker, including the remote office staff. In terms of SharePoint architecture, achieving these goals is all about workload and how it's distributed and optimized.
While there are many things you must do when designing your infrastructure, including implementing appropriate server topology and content architecture, there are critical design elements that require the use of techniques and technology not native to SharePoint and Windows. I'll take a look at two technologies, hardware load balancers and WAN accelerators, which are important elements for optimizing and distributing workload in a SharePoint infrastructure and which help fill the critical gap between what you need and what is native to SharePoint.
Load Balancing SharePoint
At a very high level, hardware load balancing is a critical element in being able to effectively and efficiently distribute workload for SharePoint. However, at a more granular level, load balancers typically offer a much more significant set of features and functionality that can provide a number of enhancements to your SharePoint infrastructure. These improvements to your infrastructure can be generally categorized into the core areas of performance, availability and security.
Performance improvements include the ability to offload SSL connections, which reduces the CPU and memory load on your server infrastructure. Availability improvements include intelligent and dynamic traffic routing to ensure a proportional load across every server in the array. Typically these load balancers support many methods for traffic allocation, including Round Robin, Weighted, Least Connections, Server Response Time Only, Server Response Time Weights, Least Local Connections, Least Local Sessions or Dynamic Weighted Predictor. In addition, many load balancers add the ability to intelligently monitor and react to changing conditions in server and application health using SNMP.
While security is enhanced through end-user access control, you can prevent SYN (TCP Synchronize) attacks by isolating your server infrastructure from TCP handshake setup and by allowing intrusion detection and prevention systems to monitor traffic between the load balancer and your SharePoint Web servers. In addition, load balancers typically have the ability to reuse TCP connections, which further reduces the burden of TCP session creation on your servers. They also generally support Transaction Rate Limiting, or TRL, which allows you to limit the number of transactions per connection. This is an excellent tool for preventing individual clients from using a disproportionate amount of server or network resources.
Optimizing the WAN Environment
WAN accelerators are an easy choice for optimizing your SharePoint infrastructure to best meet the needs of your remote-office users. In fact, they're almost a necessity for many organizations. Again, Microsoft actually does not recommend a centralized SharePoint infrastructure unless bandwidth and latency between sites is capable of providing a reasonable user experience. This recommendation also extends beyond a single centralized site. For example, if you have regional SharePoint sites, you may also have a topology that resembles multiple hubs and spokes with the smaller "spokes" or offices being good candidates for a WAN accelerator.
If you have any doubts about whether a site is a good candidate for implementation of a WAN accelerator, there are some simple methodologies to help you determine the impact of a SharePoint implementation on WAN usage. While determining the impact of SharePoint on the WAN is beyond the scope of this article, the simplest methodology requires that you determine the page and file sizes stored in SharePoint and then estimate usage patterns and compare these requirements to actual available bandwidth on the WAN connection. However, it's imperative to keep in mind that latency can be a critical issue. In fact, Microsoft states that latency is more important than bandwidth to overall performance until bandwidth is restricted to 512Kbps or less.
As an example, Microsoft shows a latency of 500ms on a T1 (1.544Mbps) WAN circuit provides approximately the same performance as a T3 (44.736Mbps) with the same latency. Because many networking IT professionals are often constrained in terms of WAN connectivity, it's important to consider WAN accelerators as the most suitable method of improving both SharePoint connectivity and consistency of experience for the end user. WAN accelerators can also be of significant benefit to your indexing architecture and your use of Business Data Catalogs (BDCs). Depending upon how your topology is designed, crawling of content sources can create significant spikes in network traffic. Microsoft even suggests that in some circumstances the content crawling bandwidth requirements can be greater than the users' bandwidth requirements. It's also worth noting that BDCs within SharePoint don't provide for any caching of data, so if your data source is remote you can place another significant load on your WAN. BDC functionality is also another element susceptible to latency issues.
In general, the enhancements offered by WAN accelerators can be categorized into the core areas of data handling, protocol acceleration and traffic management. Data handling can be further divided into compression, object (file) caching and encryption. Protocol acceleration focuses on optimizing the TCP/IP stack, particularly at the higher layers, such as layer 7 (application), and on reducing protocol "chatter" over the WAN. On some WAN appliances, this optimization also includes byte caching, which caches repetitive traffic found in the byte stream and works at the transport layer. Finally, traffic management can be subdivided into quality of service and bandwidth throttling.
While it's clear that load balancing and WAN acceleration offer both quantitative and qualitative benefits, the first question most IT pros will ask themselves is, "What can I expect in terms of bottom-line improvement in performance?" To be fair to all vendors, they can really only provide guidance in terms of real-world improvements because ultimately your infrastructure and usage patterns are unique and will determine the results for your environment. However, putting this consideration to one side, many vendors have published numbers related to performance improvements that are significant and offer a compelling reason to invest in the technology.
For example, there are a number of statistics related to WAN performance that highlight significant reductions in bandwidth usage and load times. In particular, if the cache is optimized (warmed) during normal usage, you can expect similar traffic to be reduced by up to 90 percent. In terms of the user experience, this translates from a wait time measured in minutes to a wait time measured in seconds. In addition to these performance numbers related to WAN optimization, there are some significant benefits of SSL offloading in a heavily utilized environment with very large numbers of concurrent connections to a SharePoint Web farm. In this type of scenario, server CPU utilization can reasonably be expected to drop several percentages when a load balancer is introduced and SSL termination configured. Depending on your own environment, this type of performance improvement could be significant in terms of server hardware requirements and associated costs.
There are many elements that IT pros should consider when designing a SharePoint infrastructure, including such fundamentals as implementing page designs that minimize HTTP and HTTPS requests, configuring the binary large object cache in SharePoint and enabling IIS compression. At the other end of the continuum, you must ensure your SharePoint topology is designed correctly. However, it's important to remember the techniques that are native to SharePoint and associated Windows components only go so far.
To put some of the performance numbers discussed in this article into perspective, consider the Microsoft finding that in an HTTP content crawl (for indexing), performance is reduced by 30 percent with a latency of only 100ms. There are clearly issues external to SharePoint that need to be addressed if you wish to implement an effective SharePoint infrastructure that will be used over the WAN. The remaining gap can be addressed by hardware load balancing and WAN acceleration.
In addition to addressing needs that SharePoint was not really designed to address, such as reducing network bandwidth usage, improving latency and ensuring efficient load distribution, you can achieve many improvements to such basics as document load time, application responsiveness, reliability, availability and security.