When I initially sat down to start this article, I quickly realized that you can't begin to troubleshoot performance issues until you have a sound
baseline to start with. Otherwise, the likelihood of you figuring out what is going wrong in the environment is extremely low. With this in mind, I
decided to tackle this topic from a bit of a different perspective, examining what forms the base of a solid and well-performing Microsoft SharePoint
2010 farm and working backward from there.
Performance is a tremendously broad topic when you're talking about SharePoint 2010. End users frequently have concerns such as "Saving that form took
too long," or "It felt like it took forever for me to upload a file," or -- my favorite -- "SharePoint feels slow." As IT pros, we rarely get specifics
when people complain about performance; they expect us to fix problems instantly without any details of what's really going on.
But SharePoint user education is a topic for another day. This article focuses instead on some of the main areas that you can address to ensure that
any bottlenecks users experience are not SharePoint-related and to give you that solid foundation I mentioned earlier.
Windows Server Hardware Sizing
First, you'll want to make sure that the platform that supports SharePoint is sound. To do so, you need to correctly size your hardware to support the
SharePoint tier that is being hosted. You'll also need to ensure that Windows Server has been optimized.
Table 1 lists Microsoft's minimum hardware requirements for web servers and application servers in a farm installation. Keep in mind that these are
minimum recommendations and will serve up a minimal experience. If you want to optimize performance, these numbers are not going to be anywhere close
to good enough.
Table 1: Minimum Hardware Requirements for Web and App Servers in a Farm
In most scenarios, web- and application-tier servers will experience CPU contention before RAM contention, but that will depend on your
application-pool configuration. If you load 2GB into the application pools at startup -- which you shouldn't be doing, but I've seen it happen in
highly application development-focused scenarios -- and you're running four app pools, then you've exhausted your RAM before a user even hits a page.
For the optimal RAM profile, examine what your app pools will require, multiply that number by the number of app pools that you expect to have, and
then add half again as much to ensure room for growth and the occasional application that doesn't dispose properly:
(Required RAM) ´ (# of App Pools) ´ 1.5 = Proposed RAM Profile
(For more information about application pools for SharePoint, review the Microsoft article "SharePoint Server 2010 Capacity Management: Software Boundaries and Limits." )
The proper CPU profile is going to rely primarily on your environment's balance between virtualization and hardware. Microsoft Hyper-V Server 2008 R2
supports as many as four cores per guest virtual machine (VM), and VMware vSphere Enterprise Plus supports as many as eight cores. If you need more
than eight cores, then your path lies with physical servers. I believe in virtualization as a path because of the lower total cost of ownership (TCO)
of the high availability and disaster recovery that it enables; however, each path has its own virtues. Whichever path you choose, a general
performance rule is to keep your CPU utilization at less than 50 percent per server.
Hard disk space is a fairly straightforward decision: 80GB is never going to be enough. Each web and application server will have its own Microsoft
User Location Server (ULS), IIS, and event logs; copy of the 14 hive; and WinSxS directory. Add the need for a pagefile that doubles your RAM count and
a desire to make sure that your server doesn't crash because you didn't have enough disk space. I recommend a minimum of 200GB per server -- 400GB if
you can afford it. Rather than splitting drives into multiple partitions, keep a single, larger C partition to manage growth.
SQL Server Hardware Sizing
The SQL Server tier is the one in which you'll want to make your hardware investment. If you don't give SQL Server enough horsepower, you're sunk
before you leave port. CPU and RAM are both crucial to SQL Server performance, but be aware that SQL Server will chew up as much RAM as it can get its
teeth into, regardless of load. In most cases, SQL Server takes RAM and never gives it back. CPU will trend up and down over time, but if you don't
have enough cores across which to spread the load, you'll find yourself with pegged CPUs and a poorly performing SharePoint farm. Table 2 lists
Microsoft's minimum hardware requirements for SQL Servers in a farm installation.
Table 2: Minimum Hardware Requirements for SQL Server Machines in a Farm
When sizing SQL, always consider which services you can separate out. The minimum requirements refer specifically to the relational database management
system (RDBMS) engine, not taking into account any SQL Server Integration Services (SSIS), Reporting Services (SSRS), or Analysis Services (SSAS) needs
that you might have. Separate these services onto their own hardware whenever possible, and address their specific hardware requirements as well.