SharePoint Tech Network Performance Deployment Planning and Considerations
In a recent conversation with a SharePoint customer we had some back and forth on how they could optimize their network traffic both in the datacenter and on the user side. I did a post a while back on digging into SharePoint related network performance issues. You could consider this a follow up to that as how to optimize the network traffic and understanding what you can do about it. Not all resources are here, but hopefully you'll get some info to help you get started in optimizing your SharePoint technologies related network traffic.
SharePoint traffic is HTTP or HTTPS. Inside the HTTP Packets you’ll find HTTP requests, SOAP, FPRPC, Web DAV depending on the client. The packet sizes are not determined by SharePoint tech, it simply leverages the Windows Server Network settings. Between the servers you will find some RPC (DCOM) traffic. More detail on this in the security section of the deployment guide. This guide provides the ports, detail on communication within and without the farm. By the way, session state is important for some services in MOSS 2007, but less important. Sticky sessions I've found do provide the best user experience and performance where auth is required.
Please review this performance post from the SharePoint Team blog as a baseline for information. It's an interesting review from Jeff Teeper.
Optimizing SharePoint Network Traffic
1. Authentication – Use Anonymous, Kerberos, Digest (WSSv3/MOSS 2007 only) Forms (WSSv3/MOSS 2007 only) or Basic (only use with SSL). NTLM (default) although easiest and most common is much more chatty than the others. Kerberos would be the best authentication option fpr security and for reducing traffic to DCs. (Test it... Don't forget the SPN on the service domain account) Here's a KB on how to configure it on WSS (applies to all SharePoint Tech)
2. Packet (request and response) and Window size - can be configured on client and server and network gear (i.e. Vista and Longhorn server both have TCP auto tuning and window sizing technologies) "Windows Vista, we implemented TCP auto-tuning. It enables TCP window scaling by default and automatically tunes the TCP receive window size based on the bandwidth delay product (BDP) and the rate at which the application reads data from the connection. With TCP auto-tuning, we have seen 1000% (10x) throughput improvements in internal testing over underutilized wide-area network links." (snippet from Windows Core Networking Blog)
3. Client Network Drivers - We found even Windows XP SP2 & Vista optimized traffic with updated network drivers.
4. Caching (client, server (.NET, WebParts, Pages, Layouts, etc...) and network device caching, beyond ISA in 2003/6 there are lots of options in SharePoint Server 2007) (SharePoint Server options including some dev options and server admin considerations (scroll down to cache settings). Enable the web publishing features on your MOSS 2007 site or create a "publishing site" and got to site settings on the top level site to configure.
5. Client Proxy configuration – if you’re on an intranet and going through a proxy server and you don’t need to… you could loose 2-3 seconds per page request.
6. Optimize indexing - reduce indexes. Use 1 if possible to optimize... Links in different indexes will be crawled uniquely for each index in SPS 2003. Reduce ACL changes by using NT Security groups. ACL crawling in MOSS 2007 will help here as well. Go here for a SharePoint Server and WSS feature comparison. Optimized index infrastructure optimizes the traffic and reduces round trips and reduces pulling across files it's already indexed by leveraging the change logs.
7. SharePoint Servers in Farm all on same LAN - All servers in a SharePoint farm should have no latency between them despite what version your using at least up to MOSS 2007. If web servers are in separate data centers from search or index or SQL servers you could see problems. Continuous propegation in MOSS 2007 optimizes cross server traffic. Packet routing can be optimized by having the web front ends in their own VLAN with inbound NICs and outbound NICs to SQL. Watch out when putting a firewall between front ends and Search/Query servers as RPC requests need to be fulfilled. Search requests will be super slow if search servers can't talk to each other.
8. Optimize NIC & Backup optimization - reduce backup traffic by either using a second NIC, backup from passive node, or use snapshots (MOSS 2007 or SQL 2005 both have providers). SQL logshipping and database mirroring each have their own network considerations.
Interesting Traffic Testing Results
In our analysis we compared the SharePoint HTTP/S traffic against File Servers and were pleasantly surprised with how well SharePoint handled file transfers over higher latencies (it's really the HTTP protocol that did well). It was really a comparison of HTTP traffic vs. SMB traffic. These were some simple charts that were produced while we were testing user response traffic over latencies with differing utilizations with varying bandwidths in charts below. These are not official charts or tests, simply IT black box testing (nothing official here) with a client XP SP2 IE6, server SPS 2003, WAN simulator, and a 3MB PPT. (The 3MB PPT was chosen as a top end median file size for the file type)
File Server Network Performance (below tests were against a stand alone Windows 2003 Server DFS cluster)
3 MB PPT file uploaded at varying bandwidths, latencies, and utilizations
Note the performance when less than 100ms of latency and the fact that adding more and more bandwidth has little to no impact. Also note the fact that utilization has little impact. Latency is king here.
SharePoint Network Performance (below tests were over SSL)
3 MB PPT file uploaded at varying bandwidths, latencies, and utilizations
Note the impact of utlilization, the fact that adding bandwidth is helpful up to a point, and the fact that latency does have some but not as much impact as bandwidth. We looked at this and decided to avoid 256K links. With smaller file sizes such as web pages, these results may be more acceptible at lower bandwidths.
