Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 17 ppt

MCT USE ONLY. STUDENT USE PROHIBITED
Planning for Performance and Capacity 3-27
Selecting a Farm Topology

Key Points
It is important to consider farm size and topology carefully when you size a
SharePoint 2010 solution for performance and capacity. Farm topologies for
SharePoint 2010 fall broadly into three categories:
• Small farm. A small SharePoint farm typically has two or three tiers made up
from up to five servers. Typically, there is a single database server, and WFE
servers may also perform service application roles. A two-tier, three-server farm
can serve relatively low usage load (a few requests per minute to a few
requests per second (RPS)) and a volume of data in the region of tens of
gigabytes.
• Medium farm. A topology for a medium SharePoint farm typically has three
tiers, with more than six servers. There may be multiple database servers,
multiple search servers, and application servers that are dedicated to specific
service applications. Multiple WFE servers enable many concurrent user
requests. A medium-size farm can serve a usage load of a few tens of RPS and a
data volume up to 1 terabyte.
MCT USE ONLY. STUDENT USE PROHIBITED
3-28 Designing a Microsoft® SharePoint® 2010 Infrastructure
• Large farm. A topology for a large SharePoint farm typically employs in excess
of 10–12 servers that are arranged in three tiers. In a large farm, you often
logically group servers according to the applications that the servers host. For
example, a group of three servers hosting Microsoft InfoPath® forms, or a
group of two crawl servers. A large farm can serve usage loads of hundreds of
RPS and data storage of tens of terabytes.

Additional Reading
For more information about topologies for SharePoint Server 2010, see

MCT USE ONLY. STUDENT USE PROHIBITED
Planning for Performance and Capacity 3-29
Monitoring Performance

Key Points
To size a solution correctly from a performance perspective, you should perform
monitoring of the system under load to ascertain performance characteristics,
identify bottlenecks, and establish the capability of the solution to meet business
requirements.
You can use the Performance Monitor tool in Windows Server® 2008 and
Windows Server 2008 R2 to capture performance information from performance
objects and counters. Performance objects can include hardware components such
as processor or memory. They can also include software components such as
Windows® operating system subsystems or the Microsoft .NET Framework.
You can also add the performance counters that you need to monitor to the
SharePoint Usage and Health Data Collection database, which can then provide a
single point for health and performance data. You do this by using the Add-
SPDiagnosticsPerformanceCounter Windows PowerShell™ cmdlet.
You should capture initial performance statistics under peak load to create a
baseline for how the system performs. You should then regularly revisit the
MCT USE ONLY. STUDENT USE PROHIBITED
3-30 Designing a Microsoft® SharePoint® 2010 Infrastructure
performance information for the live system. This will enable you to capture trend
data and identify any areas for performance improvement, if required.
The following table describes the system performance counters that you should
monitor on any Web server.

Counter Object Description

% Processor Time Processor This shows processor usage over a period of time. If
this is consistently too high, you may find
performance is adversely affected. Remember to
count "Total" in multiprocessor systems. You can
also measure the usage on each processor to
ensure balanced performance between cores.
- Avg. Disk Queue
Length
Disk This shows the average number of both read and
write requests that were queued for the selected
disk during the sample interval. A bigger disk
queue length may not be a problem as long as disk
reads/writes are not suffering and the system is
working in a steady state without increasing the
queue length.
Avg. Disk Read
Queue Length
Disk This shows the average number of read requests
that are queued.
Avg. Disk Write
Queue Length
Disk This shows the average number of write requests
that are queued.
Disk Reads/sec Disk This shows the number of reads to disk per second.
Disk Writes/sec Disk This shows the number of writes to disk per second.
- Available
Mbytes
Memory This shows the amount of physical memory that is
available for allocation. Insufficient memory will
lead to excessive use of the page file and an

increase in the number of page faults per second.
- Cache Faults/sec Memory This shows the rate at which faults occur when a
page is sought in the file system cache and is not
found. This may be a soft fault, when the page is
found in memory, or a hard fault, when the page is
on disk.

MCT USE ONLY. STUDENT USE PROHIBITED
Planning for Performance and Capacity 3-31
Counter Object Description
The effective use of the cache for read and write
operations can have a significant effect on server
performance. You must monitor for increased
cache failures, which are indicated by a reduction in
the Async Fast Reads/sec or Read Aheads/sec
counters.
- Pages/sec Memory This shows the rate at which pages are read from or
written to disk to resolve hard page faults. If this
rises, it indicates system-wide performance
problems.
- % Used and %
Used Peak
Paging File The server paging file, sometimes called the
swapfile, holds virtual memory addresses on disk.
Page faults occur when a process has to stop and
wait while required virtual resources are retrieved
from disk into memory. These will be more
frequent if the physical memory is inadequate.
- Total Bytes/sec Network
Interface

This is the rate at which data is sent and received
via the network interface card. You may need to
investigate further if this rate is over 40-50 percent
of network capacity. To fine-tune your
investigation, monitor Bytes received/sec and
Bytes Sent/sec counters.
- Working Set Process This indicates the current size (in bytes) of the
working set for a given process. This memory is
reserved for the process, even if it is not in use.
- % Processor
Time
Process This indicates the percentage of processor time that
a given process uses.
Thread Count
(_Total)
Process This shows the current number of threads.
Requests Total ASP.NET This shows the total number of requests since the
service was started.
Requests Queued ASP.NET Microsoft SharePoint Foundation 2010 provides the
building blocks for HTML pages that are rendered
in the user browser over HTTP. This counter shows
the number of requests that are waiting to be
processed.
MCT USE ONLY. STUDENT USE PROHIBITED
3-32 Designing a Microsoft® SharePoint® 2010 Infrastructure
Counter Object Description
Request Wait
Time
ASP.NET This shows the number of milliseconds that the
most recent request waited in the queue for

processing. As the number of wait events increases,
users will experience degraded page-rendering
performance.
Requests Rejected ASP.NET This shows the total number of requests that were
not performed because of insufficient server
resources to process them. This counter represents
the number of requests that return a 503 HTTP
status code, indicating that the server is too busy.
Requests
Executing (_Total)
ASP.NET This shows the number of requests that are
currently running.
Requests/Sec
(_Total)
ASP.NET This shows the number of requests that are
performed each second. This represents the current
throughput of the application. Under constant load,
this number should remain within a certain range,
barring other server work (such as garbage
collection or external server tools).

The following table describes the system performance counters that you should
monitor on a computer running SQL Server.

Counter Object Description
User Connections SQLServer:General
Statistics
This shows the amount of user connections
on your instance of SQL Server. If you see
this number rise by 500 percent from your

baseline, you may see a performance
reduction.
- SQLServer:Databases This object provides counters to monitor
bulk copy operations, backup and restore
throughput, and transaction log activities.
Monitor transactions and the transaction
log to determine how much user activity is
occurring in the database and how full the
transaction log is becoming. The amount of
user activity can determine the
MCT USE ONLY. STUDENT USE PROHIBITED
Planning for Performance and Capacity 3-33
Counter Object Description
performance of the database and affect log
size, locking, and replication. Monitoring
low-level log activity to gauge user activity
and resource usage can help you to
identify performance bottlenecks.
Transactions/sec SQLServer:Databases This shows the amount of transactions on a
given database or on the entire SQL Server
instance per second. This number is to help
you create a baseline and troubleshoot
issues.
Number of
Deadlocks/sec
SQLServer:Locks This shows the number of deadlocks on the
computer running SQL Server per second.
This should be 0.
Average Wait
Time (ms)

SQLServer:Locks This shows the average amount of wait
time for each lock request that resulted in a
wait.
Lock Wait Time
(ms)
SQLServer:Locks This shows the total wait time for locks in
the last second.
Lock Waits/sec SQLServer:Locks This shows the number of locks per second
that could not be satisfied immediately and
had to wait for resources.
Average Latch
Wait Time (ms)
SQLServer:Latches This shows the average latch wait time for
latch requests that had to wait.
Latch Waits/sec SQLServer:Latches This shows the number of latch requests
per second that could not be granted
immediately.
SQL
Compilations/sec
SQLServer:SQL
Statistics
This indicates the number of times the
compile code path is entered per second.
SQL Re-
Compilations/sec
SQLServer:SQL
Statistics
This indicates the number of times
statement recompiles are triggered per
second.

Cache Hit Ratio SQLServer:Plan
Cache
This indicates the ratio between cache hits
and lookups for plans.
MCT USE ONLY. STUDENT USE PROHIBITED
3-34 Designing a Microsoft® SharePoint® 2010 Infrastructure
Counter Object Description
Buffer Cache Hit
Ratio
SQLServer:Buffer
Manager
This shows the percentage of pages found
in the buffer cache without having to read
from disk. The ratio is the total number of
cache hits divided by the total number of
cache lookups since an instance of SQL
Server was started.


Note: The SQL Server performance counters are included here for the sake of
completeness. Many SharePoint architects will not be SQL Server performance experts.
You may want to discuss SQL Server performance issues with an experienced SQL Server
database administrator (DBA).
Question: What are the four common hardware components to monitor on a
server?
Additional Reading
For more information about how to monitor and maintain SharePoint Server 2010,
see

MCT USE ONLY. STUDENT USE PROHIBITED
Planning for Performance and Capacity 3-35
Performance Management Modeling in SharePoint 2010

Key Points
Performance management modeling for SharePoint 2010 includes five key steps:
1. Model. Model the farm environment that you require by establishing the
elements or features that you want your solution to provide. Also, determine
any required measures such as performance and reliability. The modeling
exercise should create:
• Expected workload and dataset (volume of data).
• Farm performance and reliability targets.
2. Design. Design the farm by using the data from the first step. The design step
should create logical and physical architecture designs.
3. Pilot, test, and optimize. Deploy a pilot environment and conduct testing
against performance targets. Where necessary, optimize the deployment to
meet performance targets or consider revising the solution (for example,
change the solution scope or revise the topology).
4. Deploy. Deploy the established solution to the production environment.
MCT USE ONLY. STUDENT USE PROHIBITED
3-36 Designing a Microsoft® SharePoint® 2010 Infrastructure
5. Monitor and maintain. Implement monitoring of capacity and performance,
identify trends and bottlenecks, and implement maintenance activities when
required.

While you initially plan your SharePoint farm, you will use the first three steps to
identify performance targets, design the farm, and perform testing to determine
whether the design meets the required performance targets.

Note: Workload describes the demand that the system must sustain. Workload typically

uses the label RPS to describe demand on the server farm. It is most common to measure
RPS by using all requests in the Internet Information Services (IIS) log except the
Authentication handshake requests (401HTTP status). You do not count these because
they bias the calculated RPS figure.
Question: How can you identify SharePoint performance issues before you create
your production environment?
Question: What resolution steps can you take to resolve a performance issue at the
pilot phase?
Additional Reading
For more information about capacity planning for SharePoint 2010, see