Much like SharePoint 2007, SharePoint 2010 has many challenges for performance planning because of the types of services that are provided as well as the multiple types of clients that are accessing content.  With all of these services provided in SharePoint 2010, the web application and SQL layers of your environment will need to scale up for additional disk, RAM and CPU in order to be serve up these applications and services.

When starting to work on performance tuning we need to understand the layers of terms that need to be addressed.  Latency, what is the perceived time that it takes once a user clicks on a page, to when it’s fully loaded.  Throughput is how many concurrent users can access information at the same time. Capacity relates to how much information is saved into your environment, this is the majority of data that your end users will care about. Reliability,

Some improvements in SharePoint 2010 for latency are lighter and faster pages that are WAN optimized.  Page load time has also been improved from navigating between pages.  Of course, these improvements are also dependant of content and customizations in your environment.

The Office Document Cache (ODC) also will help client applications upload content behind the scenes.  The ODC allows the system to only perform incremental changes as well as verifying that you are working on the most recent copy of your documents.

There are only a few hard limits, but more soft limits with SharePoint 2010.  The only hard limit that Microsoft has let us know about are 100 million items per search index, and 1 billion items when using FAST.  The other soft limits that you may come across in SharePoint 2010 are now lists and libraries support up to tens of millions of items per list, however they do have performance degradation if you try and retrieve more than 5000 items per view / query.  Some administration soft limits are:

• 150,000 site collections per web application
• 50,000 site collection per content database
• 100 GB size per content database

With these soft limits, Microsoft has provided some safe-guards to help IT Pro’s keep end users from hurting themselves.  The large list improvements allow administrators specify limits on how many items will be viewed from a view (both in the user interface, but also for developers and PowerShell scripters).  There are also improvements when site administrators try to delete a large list, with the list throttling, it denies non-site collection administrators from deleting large lists (based on your configurations of what a large list is).  However, you do have the ability to configure “happy-hour” times for when you want to script the deleting of this list when minimal users will be impacted.

There are new improvements in SharePoint 2010 to allow web front end servers to inform clients on it’s health condition.  This new function allows the server to tell these clients that it is under a high load and the clients will start to tune down the amount of requests to the web server to let the server reduce the overloaded operations.  SharePoint 2010 also gives administrators the ability to prioritize traffic that will allow information to be higher in the rendering queue and will actually block other HTTP traffic for lesser priority content until the server can get back to a healthy state.

The new Developer dashboard will allow SharePoint administrators to keep developers in check by enabling additional information for each page to determine what items may be causing load issues when end users report issues with specific sections of your deployment.

When starting to think about capacity planning, Microsoft will be providing a Load Testing kit for SharePoint 2010 as well as a tool called SPDiag 2010 for production monitoring that allows administrators to be proactive rather than reactive when dealing with server health.  The new SQL Logging database allows administrators to report on health and usage data that is actually supported by Microsoft.  This database schema will also be announced so that developers may extend the database to provide a deeper knowledge of these health and usage statistics.

Because SharePoint is so customizable there are many different ways on how to provide guidance on hardware, storage and throughput requirements.  SharePoint can have an environment from a single server that provides all services from the web front end, search indexing, search querying, and SQL storage all the way to multiple servers for each type of server role to spread out the resource pain based on the services they serve.

SharePoint 2010 will be more resource intensive because of the amount of services that are involved, so the starting point with a production farm for RAM is bumping it up to 8GB.  Because of the amount of information that needs to be shared with SQL and the intensive nature of resources at that layer, Microsoft recommends a minimum of 16GB of RAM on your SQL servers.  Of course, SharePoint 2010 is x64 ONLY, so make sure to prepare for a 64-bit environment if you want to upgrade to SharePoint 2010, both from the SharePoint layer but also the SQL layer.

[“Brian”]