Capacity Planning Presentation Notes - Colorado SharePoint User ...

ballooncadgeInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 4 χρόνια και 7 μέρες)

71 εμφανίσεις

Capacity Planning:

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
terative process
that needs to take in all of the customer’s requirements and making an educated decision regarding
hardware.

Common Questions:


How much hardware do we need?


Should we implement a server farm?


Do we need SQL Server?


How much data can w
e store?


What benefits are there in using 64
-
bit HW?


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.

Module Agenda:

We will begin the module with Guidance and Recommendations from

Microsoft and then take a look at
the SharePoint Capacity Planning Tool.

Performance
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
of SharePoint
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
Product Group.

Object Categories:

Objects include site Object, People Object, Search Objects, Logical Architecture Objects, and Physical
Objects.

SharePoint Containment Hierarchy:

A SharePoint web farm is made up of servers …

A SharePoint Web Application
Zone is

equivalent to an IIS Web Ap
plication



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
ites

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
d on
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
guidelines.

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
additional hardware.

50 million indexed documents per Search Index, dedicated index server will be required.

The farm is built on
64

bit architecture for all tiers. Network is a gigabit Ethernet. WFE Server
connecting to SSP and SQL can be quite

he
avy.

Single server with everything on it, pushed to failure and then added additional servers. Distributed
farm, then additional WFE.

Recommendations & Guidelines

http://technet.microsoft.com/en
-
us/library/cc262787.aspx

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
t quickly
drops around 2000 items in the library.

Other Considerations:

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
plateau.

Other

Recommendations:

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 Profiles:

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



Operation

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
tarting point…


Sample Usage Profile (WSS Collaboration):

Critically import in design and testing. Create a web test that would be representative of the actions on
the left.

Throughput Requirements:

Determine concurrency
of users. Concurrency is the percentage of all users using the system at the
same time.

1 RPS = 1000 users @ 10% concurrency.

Don’t plan for average concurrency, plan for peak load + 10%.

Other Factors:

There are some factors that can influence throughp
ut targets.

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
planned.

Always profile your web parts …

Latency:

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.

Multi
-
Server:

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.

Scaling Out:

Much easier to scale out.

64 bit vs. 32 bit:

WSS 3.0 / MOSS work on both. 64
-
bit recommendation.

32
-

bit can directly address only a 2GB Me
mory Address Space


64
-
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 version


64
-
bit HW Prioritization

SQL Server
-
>
Index
-
>
Excel
-
>
Search
-
>
WFE

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
system.

With
the WFE, it depends on how you have configured them. You may need to increase the overall
memory if you are using Output Caching.

Storage Considerations:

Primary Metric: Document Storage


not straight conversion. File system is more efficient at storing

files.

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
sources.

Query Server: 1 x index size


Propagating from index server so needs additional space.

SQL Planning:

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
(
SP2+
)

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
s Up

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
between 50%
-
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.

Storage Considerations:


Download “Performance Recommendations for Storage Planning and Monitoring “

whitepaper
(
http://go.microsoft.com/fwlink/?LinkID=105623&clcid=0x409
)

Information architecture recommendations

Physical topology guidance

Network topology recommendations

MONITORING, MAINTAINING, AND TROUBLESHOOTING

Physical Servers

Disk counters to monitor

Disk reco
mmended practices

SQL Server recommended practices

Troubleshooting



Plan for Performance and Capacity (Office SharePoint Server)


htt
p://technet2.microsoft.com/Office/en
-
us/library/8dd52916
-
f77d
-
4444
-
b593
-
1f7d6f330e5f1033.mspx?mfr=true



Design the Logical Architecture


http:
//technet2.microsoft.com/Office/en
-
us/library/1a8e707a
-
a9b9
-
4cc1
-
9daa
-
08d450692d2d1033.mspx



Determine Hardware and Software Requirements (Office SharePoint Server)


http://technet2.microsoft.com/Office/en
-
us/library/4d88c402
-
24f2
-
449b
-
86a6
-
6e7afcfec0cd1033.mspx



Tools for Performance and Capacity Planning (Office SharePoint Server)


http://technet2.microsoft.com/Office/en
-
us/library/301ed832
-
95da
-
4251
-
b266
-
7be6288f7ea01033.mspx



Visual Studio 2005 Team Test Edition: Testing
Demos
http://www.microsoft.com/downloads/details.aspx?FamilyId=88F7CB8B
-
473B
-
4ED5
-
BA47
-
ABBC06D0048E&displaylang=en