I’ve run into a few customer environments of late where the performance of SharePoint was unacceptable, however, the real problem isn’t SharePoint. It’s been either disk performance or it has been network performance. So I wanted to lay out a few quick suggestions for high performance SharePoint implementations. The trick is, I’ll tell you they have nothing to do with SharePoint. It’s all about good general network performance and good SQL server performance.
Disks from the Ground Up
So if you want good performance from your system you have to get it right from the ground up. Here are some suggestions on the disk side:
- Other than for a SQL Cluster … Use Direct Attached storage — All things being equal, you’re going to find that DAS is faster. I’ll point you to a SQL Team.com article “Which is Faster: SAN or Directly-Attached Storage” where they say that the generalization I’m making is bad so you can make your own decision, however, for equal performance drives, configured the same way DAS is faster. You’ll never get slowed down by anyone else and you have less infrastructure to push your way through. (But read the rest of the items for this to fit in.)
- Buy smaller, faster drives — Typically we think of storage in terms of capacity. I bought 5 TB of disk or I need 10TB of disk. Rarely do we think of the number of IO operations we need to get from a disk. That’s a big mistake. For high performance systems we need to be thinking about how many operations each disk can produce. That means more, smaller, faster disks. By the way, SATA drives are MUCH slower than their SAS cousins. You’re looking for SAS drives with the fastest spin rate you can find, in sizes that are adequate for your needs.
- RAID 10 is twice as good as RAID 5 (mathematically speaking) — OK, it’s hokey, but it’s true. When you’re looking for performance you want to make an array of drives with RAID10 not RAID5. RAID5 is still appropriate for long term storage. However, RAID10 is more appropriate for any system you want performance from. (No it’s not twice as good, I was playing on the 10 vs. 5)
- Partition Alignment Counts — A good buddy of mine, Jimmy May has developed a reputation for being the man with the answers about partition alignment. If you’ve not seen him deliver one of his decks on partition alignment — make it a point to do that. Jimmy’s demonstrated over 30% performance improvements by just aligning the disk partition correctly. (Correctly being relative to how the controller and drives are setup.)
SQL Server is Your Friend
Once you get the disks right you’re on the right track. The next step is to configure SQL Server correctly. Here are a few helpful tips:
- Memory is Good, More Memory is Better — SQL server has got to be the product at Microsoft which has got memory management right. If you feed SQL server memory it will feed you back better performance. Of course there’s the law of diminishing returns but with memory being cheap — go big.
- TempDB is critical — The tempdb in SQL server is it’s workspace. If it doesn’t perform well, then the system doesn’t perform well. Look at KB 328551 about allocating many TempDB files across multiple LUNs to improve performance. Or the article Optimizing tempdb Performance.
- [SharePoint Specific] Look at the Database Maintenance for Microsoft SharePoint Products and Technologies white paper
- [SharePoint Specific] The search DB will be hot — The _SEARCH database for SharePoint will be VERY busy. It’s going to need some serious disk resources. Look at SQL File groups and Search for specifics on how file groups may help.
One of the other areas that tends to bite people is network performance. Whether it’s a 100MB hub in the server rack. (Meaning those 1GB NICs don’t get to go that fast) or silly requirements for switch diversity, you’ve got to be networking smart. Here’s a few tips:
- All NICs in all SharePoint farm servers (SQL included) are locked at 1GB/Full. If you can’t network at 1GB per server don’t bother, you’re not going to have good performance.
- Team or Link Aggregate multiple NICs in your servers — Every server should have at least 2 NICs. Those NICs should be link aggregated. For SharePoint Front End Web servers you can split them for web traffic and background traffic — but honestly, I’d link aggregate them too if you can.
- Don’t do switch diversity — This is a hard one. Folks want to do switch diversity (one NIC on one switch and the other NIC on a different switch) so they can survive a switch failure. Observationally, something isn’t configured correctly and you still go down. Worse, the switches RARELY have enough bandwidth between them so all of your traffic slows down because the switches saturate their cross-connect link. It’s just not worth doing this unless you know for certain you can get it right.
I’m sure there are tons of other things to think about — these are just the ones that have bit clients in the last few months.
How do you split two NIC’s up for web and background traffic, as you state above?
Well, the short is put your two network interfaces on two different subnets. Make sure one of them is set where the SQL server is accessed through the same subnet. Don’t set a default gateway and don’t register this address in the load balancer. You’ll end up with user traffic on one NIC and database traffic on the other NIC.
Well, this is useful for me in real sense. I like the way it is mentioned here with full expression.