Understanding the capabilities of SharePoint and matching those capabilities to the needs of the
organization and then determining the appropriate hardware and software requirements.
Capacity Planning is a process.
SharePoint can be
configured, deployed and used in a variety of ways. It can be used primarily as a
collaboration environment, a corporate intranet, or even a public facing internet site.
Some environments may require heavy Excel Services, while others may not. It is an i
that needs to take in all of the customer’s requirements and making an educated decision regarding
How much hardware do we need?
Should we implement a server farm?
Do we need SQL Server?
How much data can w
What benefits are there in using 64
How many users can our environment support?
How many sites can we run on our servers?
How do we validate our design?
Our goal today is that you will leave with a better understanding of SharePoint
2007 platform and
understand some of the recommendations from the SharePoint Product Group.
We will begin the module with Guidance and Recommendations from
Microsoft and then take a look at
the SharePoint Capacity Planning Tool.
and Capacity Planning:
The guidance is comprised of four components: Software Boundaries, Throughput Targets, Data
Capacity, and Hardware. The first three activities focus on understanding your business requirements
and designing a solution while the fou
rth area involves testing and tuning and validating that your
solution will satisfy the requirements and provide expected performance.
Plan for Software Boundaries:
The first step in the process is to take into consideration the actual software boundaries
2007. Each of the features and objects that can be implemented has scale limitations. We will take a
look at these objects, how hardware affects scalability, and review the test finding from the SharePoint
Objects include site Object, People Object, Search Objects, Logical Architecture Objects, and Physical
SharePoint Containment Hierarchy:
A SharePoint web farm is made up of servers …
A SharePoint Web Application
equivalent to an IIS Web Ap
Each web applications is comprised of one or more databases …
Site Collections are the center of where the information is stored for users and can store …
Within each SC we have Sites …
Each sub site contains Lists …
List Items … Folder Item si
ts between the list and item level as a container.
Test Results and Findings:
SQL Server used as the content store
Can scale up and out
When configured properly, can scale to millions of users and terabytes of data
Can store millions of documents and Web s
Provides a means to delegate administration
Design the farm in accordance with the software and hardware boundaries.
Software Scalability vs. Hardware Scalability:
There are very few hard limits within SharePoint. Most of the recommendations are base
performance. It should be pointed out that just by adding hardware to the farm does not necessarily
add to the capacity for data objects beyond their recommended limits. But it can increase overall farm
throughput which may be necessary as the data
objects approach their recommended limits and
There are certain scale limitations that will not change no matter how much hardware you throw at it.
At the same time, in order to provide performance as you get closer to these limits you may nee
d to add
50 million indexed documents per Search Index, dedicated index server will be required.
The farm is built on
bit architecture for all tiers. Network is a gigabit Ethernet. WFE Server
connecting to SSP and SQL can be quite
Single server with everything on it, pushed to failure and then added additional servers. Distributed
farm, then additional WFE.
Recommendations & Guidelines
Test Results and Finding:
Most of us understand that there are many benefits to SharePoint scalability and un
derstand why it is
such a compelling web server platform, however, it is important to know
that if you don’t respect the
recommended guidelines, performance can suffer.
Graph: Throughput decreases as the number of site in a single content database increases.
You need to understand the limits and recommendations and use the new stsadm command
mergecontentdb) to move the site collections into new content database to increase performance and
keep it high
Document Library vs. Document Library with Folders:
Document Libraries can store up to 5 million documents. If you don’t use folders, throughpu
drops around 2000 items in the library.
Throughput vs. number of Web Server:
Test finding showed plateau at 5:1 (YMMV)
After 5, the capacity of the database server was nearly 100% and overall farm performance
Carefully plan your site hierarchy and design
Minimize # Web applications and application pools
Limit # of Shared Service Providers
Sound Business Case!!!!
Increases processor and memory usage.
Plan for database growth
Follow data and f
eature best practices and suggested limits
Usage profile == User community’s behavior
What are the user’s doing?
How often are they doing it?
How many users are on
line at any given time?
Distribution of requests across content
types and frequency
Existing solution in place? Mine IIS logs
WebTrends? LogParser? Allow you to import IIS log files into SQL tables and use T
SQL against the
table. Bottlenecks and increasing performance?
Leverage usage profiles provided in configura
tions tested by Product Group as s
Sample Usage Profile (WSS Collaboration):
Critically import in design and testing. Create a web test that would be representative of the actions on
of users. Concurrency is the percentage of all users using the system at the
1 RPS = 1000 users @ 10% concurrency.
Don’t plan for average concurrency, plan for peak load + 10%.
There are some factors that can influence throughp
Caching can have a tremendous impact on throughput.
Custom web parts can cause major performance issues and risk and must be well thought out and
Always profile your web parts …
Remember to use HTML best practices. <table><
row><cell>value</cell><row></table> use rows in
Table tag, increase perceived performance.
SharePoint is a web application, use web application best practices.
Keep payload down!!!
How SharePoint Scales:
MOSS supports x32 and x64. Topology restrictions no longer exist. All sites in MOSS are built on WSS!!!
Single Server Example:
Provides no redundancy with no scale out.
Minimum you should start with.
CA should be hosted on the app server
and another server as a backup. You can use STSADM to create a
new instance of CA on another server.
Much easier to scale out.
64 bit vs. 32 bit:
WSS 3.0 / MOSS work on both. 64
bit can directly address only a 2GB Me
mory Address Space
bit supports up to 1,024 GB Memory (Physical and/or Addressable)
Larger # of Processors
Enhanced Bus Architecture
WSS 3.0 and MOSS 2007 are last 32
bit HW Prioritization
SQL Server can take advantage of the extra memory so it makes sense to make SQL a higher priority.
Index server is very processor intensive.
Excel workbooks may have custom defined functions, but it depends on how your users are using the
the WFE, it depends on how you have configured them. You may need to increase the overall
memory if you are using Output Caching.
Primary Metric: Document Storage
not straight conversion. File system is more efficient at storing
Plan for 1.2
1.5 x file system size for SQL Server
Note: metric is closely tied to RAID level used on SQL disks
Secondary Metric: Index Size
Index Server: 30%
50% of total size of ALL content indexed for a single server. Not stored in DB, stored
on actual file system. This is a pessimistic number, depends on number of unique terms and content
Query Server: 1 x index size
Propagating from index server so needs additional space.
Install SQL Server on a dedicated server th
at is not running any other farm roles
. SQL server is the heart
and soul of the farm. Much easier to scale.
Highly recommended that SQL Server be installed on 64
bit HW and OS
Host SharePoint Products and Technologies on SQL Server 2005 with the latest Service Pack
Ensure the SQL Server I/O channels to the disks are not shared by other applications, such as the swap
file and IIS logs.
Consider Scaling Out Server as well a
Monitoring Physical Servers:
To monitor servers in the farm, add some of the major performance counters are listed …
Processor: % Processor Time: _Total. On the computer running SQL Server, this counter should be kept
75%. In case of cons
tant overloading, investigate whether there is abnormal process
activity or if the server needs additional CPU.
Anything over 75% starts queuing up SQL which can bottleneck the entire system.
System: Processor Queue Length: (N/A). Monitor this counter to e
nsure that it remains below two times
the number of Core CPUs.
Memory: Available Mbytes: (N/A). Monitor this counter to ensure that you maintain a level of at least
20% of the total physical RAM free.
Memory: Pages/sec: (N/A). Monitor this counter to ensur
e that it remains below 100.
Download “Performance Recommendations for Storage Planning and Monitoring “
Information architecture recommendations
Physical topology guidance
Network topology recommendations
MONITORING, MAINTAINING, AND TROUBLESHOOTING
Disk counters to monitor
SQL Server recommended practices
Plan for Performance and Capacity (Office SharePoint Server)
Design the Logical Architecture
Determine Hardware and Software Requirements (Office SharePoint Server)
Tools for Performance and Capacity Planning (Office SharePoint Server)
Visual Studio 2005 Team Test Edition: Testing