PerformancePoint Capacity Planning - - Get a

PerformancePoint® Capacity Planning This document is provided “as-is”. Information and views expressed in this document, including URL and

other Internet Web site references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious. No real association

or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft

product. You may copy and use this document for your internal, reference purposes.

© 2010 Microsoft Corporation. All rights reserved.

PerformancePoint Capacity Planning

Microsoft Corporation

April 2010

Applies to: PerformancePoint Services

Summary: This performance and capacity planning document provides guidance on the footprint that usage of PerformancePoint® Services has on topologies running SharePoint Server 2010.

This white paper addresses the following scenarios:

Internet publishing site

Intranet publishing site

Enterprise wiki

Contents

Contents ................................................................................................................................................... 3 Estimate performance and capacity requirements for PerformancePoint Services................................................ 4 Test farm characteristic............................................................................................................................... 4

Workload ............................................................................................................................................ 4

Test definitions .................................................................................................................................... 4

Test mix ....................................................................................................................................... 5

Hardware setting and topology .............................................................................................................. 6

Lab hardware ................................................................................................................................ 6

Topology ...................................................................................................................................... 7

Dataset............................................................................................................................................... 8 Test results ............................................................................................................................................... 9

Effect of front-end Web server scale on throughput .................................................................................. 9

Overall scale ................................................................................................................................. 9

Hardware cost per transaction for an Unattended Service Account configured data source .................... 10

2M farm results ........................................................................................................................... 11

3M farm results ........................................................................................................................... 12 Recommendations .................................................................................................................................... 12

Hardware recommendations ................................................................................................................ 12

Scaled-up and scaled-out topologies .................................................................................................... 13

Estimating throughput targets ............................................................................................................. 14

Optimizations .............................................................................................................................. 14

Dynamically sized charts .............................................................................................................. 14

Common bottlenecks and their causes ............................................................................................ 14 Troubleshooting performance and scalability ................................................................................................ 15

Performance monitoring ...................................................................................................................... 15

Web servers ...................................................................................................................................... 16

Database servers ............................................................................................................................... 16 Related resources ..................................................................................................................................... 16

Estimate performance and capacity

requirements for PerformancePoint Services

In this article: Test farm characteristics Test results Recommendations Troubleshooting This performance and capacity planning document provides guidance on the footprint that usage of PerformancePoint Services has on topologies running Microsoft® SharePoint® Server 2010. Users can find more information on performance and capacity in PerformancePoint 2007 here.

Test farm characteristics

There are several possible configurations that can be used when setting up a test environment for capacity planning. Based on customer recommendations and feedback, the PerformancePoint team settled on what it considers to be a set of common characteristics for hardware, topology, workload, and datasets. This section describes what those are.

Workload

Because PerformancePoint Services is a data driven service application, and because it uses a number of different data sources, with the ability to call data from each one simultaneously, the most advantageous scenario to measure workload is to create one, average-sized customer dashboard against which users can make various tuning settings. In order to measure workload, we will use a medium-sized dashboard consisting of two filters linked to a scorecard, two charts, and a grid configured against a single Analysis Services data source. We will then change the filters and navigate charts and grids while monitoring workload on the components of the farm.

Test definitions

This section defines the test scenarios and provides an overview of the test process that was used for each scenario. Detailed information such as test results and specific parameters are given in each of the test results sections later in this article.

Test Name Test Description

Render a dashboard and change a random filter five times

1. Render the dashboard.

2. Select a random filter and filter value and wait until the dashboard is re-rendered.

3. Select another random filter and filter value and wait until the dashboard is re-rendered.

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

4. Repeat three more times randomly selecting a filter and filter value.

Render a dashboard, select a chart, and drill down and up five times


2. Select a random member on a chart and drill down.

3. Select another random member on the chart and drill down.

4. Select another random member on the chart and drill up.

5. Select another random member on the chart and drill down.

6. Select another random member on the chart and drill up.

Render a dashboard, select a grid, and drill down and up five times


2. Select a random member on a grid and expand the member.

3. Select another random member on the grid and expand the member.

4. Select another random member on the grid and collapse the member.

5. Select another random member on the grid and expand the member.

6. Select another random member on the grid and collapse the member.

Test mix

A single test mix was used that consisted of the following percentages of tests started.

Test Name Test Mix

Render a dashboard and change a random filter five times

80%

Render a dashboard, select a chart, and drill down and up five times

10%

Render a dashboard, select a grid, and drill down and up five times

10%

Microsoft Visual Studio® 2008 Load Testing tools were used to create a set of web tests and load tests that would simulate users randomly changing filters and navigating on grids and charts. The tests reported on in this article were conducted with a normal distribution of 15 second think times with a think time between test iterations of 15 seconds. The percentage of new users is <insert here>. A

user step load pattern was used to gradually add users until the response time of the AJAX rendering call to generate a scorecard or report reached a maximum 2 seconds. Server resources including CPU, Memory, and other counters were then averaged over a 15 minute time period after the maximum user load was reached. The test mix above was run twice against the same medium-sized dashboard. First, the data source authentication was configured to use the Unattended Service Account which uses a common account to request the data. The data results are identical for multiple users and PerformancePoint can utilize caching to improve performance. Second, the data source authentication was configured to use Per-User Identity which uses the identity of the authenticated user to request the data. Since the data results could be different, no caching can be shared across users. It is important to note that the specific capacity and performance figures presented in this article will be different from the figures in real-world environments. The figures presented are intended to provide a starting point for the design of an appropriately scaled environment. After you have completed your initial system design, test the configuration to determine whether your system will support the factors in your environment.

Hardware setting and topology

Lab hardware

To provide a high level of test-result detail, several farm configurations were used for testing. Farm configurations ranged from one to three web servers and a single database server running Microsoft SQL Server® 2008. Testing was performed by scaling up virtual users until the hardware reached an observed maximum capacity. All Web server computers and the database server were 64-bit, and the client computers were 32-bit. Unless otherwise stated, an enterprise default (no special runtime configurations, and so on) installation of SharePoint Server 2010 was performed. The following table lists the specific hardware that was used for testing.

Web Front Ends Application Server

SQL Server Analysis Services

Processor(s) [email protected] [email protected] [email protected] [email protected] GHz

RAM 16 GB 32 GB 16 GB 64 GB

Operating System

Windows Server® 2008 R2 Enterprise x64

Windows Server 2008 R2 Enterprise x64



Storage & its geometry (inc. SQL Server disks configuration)

50 + 18 + 205 GB ??

50 + 18 + 300 GB ? See SQL Server Disk Geometry Table

NIC 1x1 gigabit 1x1 gigabit 1x1 gigabit 1x1 gigabit

Authentication NTLM,Kerberos NTLM,Kerberos NTLM,Kerberos NTLM,Kerberos

Topology

The following diagram shows the topologies that were used in the testing for PerformancePoint Services. We arrived at the following topology configurations by adding servers when we witnessed bottlenecks at either the app server or at the WFE.

2M Farm

Front end Back end

Database Servers

SQL Server 2008

Web and Application Servers

Processor [email protected] GHz

RAM 32 GB

Storage 410 GB

NIC Speed 1 GB Full


RAM 16 GB

Storage 272 GB

NIC Speed 1 GB Full

Database Servers

Web Servers SharePoint Server 2010

pre-release version

- Web plus Central

Administration

- Application server running

Secure Store Service

PerformancePoint Services

3M Farm

Front end Back end

Database Servers

SQL Server 2008

Web and Application Servers


RAM 32 GB

Storage 410 GB

NIC Speed 1 GB Full


RAM 16 GB

Storage 272 GB

NIC Speed 1 GB Full

Database Servers

Web Servers SharePoint Server 2010

pre-release version

- Web plus Central

Administration

Application Servers SharePoint Server 2010

pre-release version

Services hosted:

PerformancePoint Services, Secure Store

Services

Dataset

The Adventure Works Dashboard contains two filters linked to one scorecard, two charts, and a grid and is based upon the Adventure Works 2008 Analysis Services cube.

Filter Dimension Members Display Type

Geography Filter Member Selecor Geography.Geography Tree

Time Filter Time Intelligence Calendar

Table 1: Filter Set for Capacity Planning Dashboard

Title Series/Rows (for Grids)

Bottom Axis/Columns (for Grids)

Background

Sales by Country (Chart)

Customer Geography Date Month of Year Internet Sales Amount

Sales Last 12 Months (Chart)

Product Categories Last 12 Months Customer Geography

Internet Sales Amount

Summary (Chart) Product Categories Date Calendar Geography

Gross Profit Margin

Top 5 Product Categories by Country (Grid)

Product Categories Date Calendar

Internet Sales Amount

Customer Geography

Table 2: Sales by Country Chart

Name Compare To Number Format Data Mappings Calculation

Percent Growth

1,234,567.89% Custom Formula

((Current - Previous)/Previous)*100

Default

QTD $1,234,568 Internet Sales Amount (AdventureWorks Cube)

Time Formula: QuarterToDate

Default

Percent Growth Target

Percent Growth

1,234,568% Custom Formula (AdventureWorks Cube)

iif(([Measures].[Internet Sales Amount], [Date].[Calendar].CurrentMember) > 0, 20, null)

Default

QTD Target QTD $1,234,568 Internet Sales Amount (AdventureWorks Cube)

Time Formula QuarterToDate-1

Default

Table 3: Internet Sales Amount Scorecard Details

The largest dashboard used to measure server resources consisted of a scorecard, an analytic grid, and two analytic charts. This dashboard also contained two filters that were used to change the values inside each of the dashboard objects. The chart sizes within each SharePoint zone did not contain specified height or width values. Rather, they were set dynamically (or set to auto-size). The characteristics of each element included the following. These are the sizes before any drill-down or filter values were applied:

Scorecard Grid Chart 1 Chart 2

5 columns X 4 rows (20 cells)

5 columns X 4 rows (20 cells)

Stacked bar Line

Test results

The following tables show the test results for the PerformancePoint medium dashboard in SharePoint Server 2010. For each group of tests, only certain specific variables are changed to show the progressive impact on farm performance. For information about bottlenecks in SharePoint Server 2010, see the Common bottlenecks and their causes section later in this article.

Effect of front-end Web server scale on throughput

Overall scale

The two tests in the following table show how the addition of business logic and complex controls affects farm throughput. Differences between the tested form templates are shown in the table at the end of this section. We want RPS values when the AJAX rendering request hits 2s.

Topology Baseline solution Max (RPS) Baseline Recommended (RPS)

1 front-end Web server and application server, 1 SQL Server (1x0x1)

325 162

?x?x1 633 316

?x?x1 1076 538

?x?x1 1052 526

?x?x1 1052 526

The following graph shows that the addition of business logic and complex controls does not necessarily affect farm throughput in a linear manner. Throughput significantly improves for both test solutions at four Web servers. The trend lines are similar for both test solutions. In summary, when business logic and complex controls are used in a form, the demand on Web servers in the farm is increased and may indicate that you should add Web servers to the farm.

The following table shows the variables in form template design for the complex form solution.

Hardware cost per transaction for an Unattended Service

Account configured data source

Tests were run on stepped out topologies. The first was run on a 1x1 farm (one C and application server, one instance of SQL Server). On a 1x1 farm, the front-end Web server and application server are

0

200

400

600

800

1000

1200

1x1 2x1 4x1 6x1 8x1

RP

S

Topology

Max and Recommended RPS per Form Type

Baseline solution Max (RPS)

Baseline Recommended (RPS)

on the same physical server. The system memory and CPU usage is the same. Since PerformancePoint Services is more application server intensive than front end Web server intensive, subsequent tests scale out the application server. The resulting values are outlined in the following tables. For each topology, tests were run against application security (using the unattended service account) and per-user security using Kerberos.

Scorecard Dashboard

Scorecard Metric 10 RPS 20 RPS 40 RPS (Take ½ users from Max at 2 seconds)

79 RPS (312 Users)

CPU Metrics Avg CPU on SQL Server at Peak User Load

1.00 1.22 2.39 4.35

Avg CPU on front-end Web server at Peak User Load

91.7 96.1

Avg App CPU at Peak User Load

52.3(same) 96.1(same)

Latency Avg. latency of AJAX request to render view

0.19 sec 0.37 sec 0.36 sec 2 seconds

Memory Avg Private Bytes of SharePoint front-end Web server w3wp (front-end Web server)

14.5 of total

26% of total

15410 MB – 36.9% of total

11.6 GB

Avg Private Bytes of PerformancePoint w3wp (Application Server)

11.6 GB (same)

2M farm results

User Count 50 150 250 360

General Test Time - Minutes 28 24 22 18

Computer Information (front-end Web server/Server)

Ave CPU% 19.20% 57.70% 94.00% 96.70%

Total Renders/Sec 10.73 31.72 49.27 49.67

Table 4: Application Security 2M Farm (1WFE/Application Server + 1 SQL Server)

User Count 50 100 150 200



Ave CPU% 30.80% 61.30% 86.50% 93.30%


Table 5: User Security 2M Farm (1 WFE/Application Server + 1 SQL Server)

3M farm results

User Count 100 250 400 540



Ave CPU% 11.00% 28.40% 42.90% 45.60%

Computer Information (Application Server)

Ave CPU% 24.50% 61.60% 93.60% 95.10%


Table 6: Application Security 3M Farm (1 WFE + 1 App Server + 1 SQL Server)

User Count 50 120 180 240



Ave CPU% 5.24% 12.20% 17.20% 19.20%

Computer Information (Application Server)

Ave CPU% 24.60% 57.20% 81.30% 88.80%


Table 7: User Security 3M Farm (1 WFE + 1 App Server + 1 SQL Server)

Recommendations

This section provides general performance and capacity recommendations. Use these recommendations to determine the capacity and performance characteristics of the starting topology that you created using the Topologies for SharePoint Server 2010 model to decide whether you have to scale out or scale up the starting topology.

Hardware recommendations

http://technet.microsoft.com/en-us/library/cc263199(office.14).aspx

For specific information about minimum and recommended PerformancePoint system requirements, see the table below.

Hardware Operating Systems Additional Requirements

Minimum

Single, Dual-Core 64-bit CPU (x64)

2.5 GHz 4 GB RAM 1 GB Available

Disk Space 100 MB

Network Interface

Windows Server 2008 64-bit

Windows Server 2008 R2 64-bit (Win 7 server) (+QFE)

Office SharePoint Server 2010 Enterprise Edition

Recommended

Two, Dual-Core 64-bit CPUs (x64)

4 GB RAM 5 GB Available

Disk Space 7200 RPM IDE

Drive 1000 MB

Network Interface

Same as minimum above Same as minimum above

Note: Memory requirements for Web servers and database servers depend on the size of the farm, the number of concurrent users, and the complexity of features and pages in the farm. The memory recommendations in the following table may be sufficient for a small or light usage farm. However, memory usage should be carefully monitored to determine whether more memory must be added.

Scaled-up and scaled-out topologies

To increase the capacity and performance of one of the starting-point topologies, you can do one of two things. You can either scale up by increasing the capacity of your existing server computers or scale out by adding additional servers to the topology. This section describes the general performance characteristics of several scaled-out topologies. The sample topologies represent the following common ways to scale out a topology for PerformancePoint Services scenario:

To provide for more user load, add Web server computers.

To provide for more data load, add capacity to the database server role by increasing the capacity of a single (clustered or mirrored) server, by upgrading to a 64-bit server, or by adding clustered or mirrored servers.

Maintain a ratio of no more than eight Web server computers to one (clustered or mirrored) database server computer. Although testing in our lab yielded a specific optimum ratio of Web servers to database servers for each test scenario, deployment of more robust hardware, especially for the database server, may yield better results in your environment.

Estimating throughput targets

Many factors can affect throughput. These factors include the number of users; the type, complexity, and frequency of user operations; the number of postbacks in an operation; and the performance of data connections. Each of these factors can have a major impact on farm throughput. You should carefully consider each of these factors when you plan your deployment. SharePoint Server 2010 can be deployed and configured in a wide variety of ways. As a result, there is no simple way to estimate how many users can be supported by a given number of servers. Therefore, make sure that you conduct testing in your own environment before you deploy SharePoint Server 2010 in a production environment.

Optimizations

The following sections discuss methods for optimizing farm performance.

Dynamically sized charts

A dynamically sized chart is any chart that doesn’t have an explicit width and height. By default, charts added to a dashboard are dynamically sized charts. The width and height of these charts are configured based upon the zone settings of the dashboard which are usually configured to specify a percentage of the dashboard page for width and height. The chart’s dimensions, width and height, are then dynamically sized based upon the user’s browser window and the layout of the dashboard. Each time a charts is requested, the chart image is cached based upon the width and height of the image. If using dynamically sized charts, a chart image is cached for each unique browser window width and height. Although this doesn’t significantly change the response time of viewing a chart, it could lead to large memory consumption on the application server PerformancePoint Services application pool. You can monitor the Private Bytes of the application pool for PerformancePoint Services to determine the memory consumption. The above test results included two dynamically sized charts randomly sized between 400 and 500 pixels in width and height. In the Unattended Service Account configured data source test, you can reduce the above memory consumption numbers by approximately XX GB if your charts are fixed in width and height.

Common bottlenecks and their causes

During performance testing, several different common bottlenecks were revealed. A bottleneck is a condition in which the capacity of a particular constituent of a farm is reached. This causes a plateau or decrease in farm throughput. The following table lists some common bottlenecks and describes their causes and possible resolutions.

Troubleshooting performance and scalability

Bottleneck Cause Resolution

Database contention (locks)

Database locks prevent multiple users from making conflicting modifications to a set of data. When a set of data is locked by a user or process, no other user or process can modify that same set of data until the first user or process finishes modifying the data and relinquishes the lock.

To help reduce the incidence of database locks, you can:

Distribute submitted forms to more document libraries.

Scale up the database server.

Tune the database server hard disk for read/write.

Methods exist to circumvent the database locking system in SQL Server 2005, such as the NOLOCK parameter. However, we do not recommend or support use of this method due to the possibility of data corruption.

Database server disk I/O

When the number of I/O requests to a hard disk exceeds the disk’s I/O capacity, the requests will be queued. As a result, the time to complete each request increases.

Distributing data files across multiple physical drives allows for parallel I/O. The blog SharePoint Disk Allocation and Disk I/O (http://go.microsoft.com/fwlink/?LinkId=129557) contains much useful information about resolving disk I/O issues.

Web server CPU utilization

When a Web server is overloaded with user requests, average CPU utilization will approach 100 percent. This prevents the Web server from responding to requests quickly and can cause timeouts and error messages on client computers.

This issue can be resolved in one of two ways. You can add additional Web servers to the farm to distribute user load, or you can scale up the Web server or servers by adding higher-speed processors.

Performance monitoring

http://go.microsoft.com/fwlink/?LinkId=129557

http://go.microsoft.com/fwlink/?LinkId=129557

To help you determine when you have to scale up or scale out your system, use performance counters to monitor the health of your system. Use the information in the following tables to determine which performance counters to monitor, and to which process the performance counters should be applied.

Web servers

The following table shows performance counters and processes to monitor for Web servers in your farm.

Performance counter

Apply to object

Notes

Processor time Total Shows the percentage of elapsed time that this thread used the processor to execute instructions.

Memory utilization

Application pool

Shows the average utilization of system memory for the application pool. You must identify the correct application pool to monitor.

The basic guideline is to identify peak memory utilization for a given Web application, and assign that number plus 10 to the associated application pool.

Database servers

The following table shows performance counters and processes to monitor for database servers in your farm.

Performance counter

Apply to object Notes

Average disk queue length

Hard disk that contains SharedServices.mdf

Average values greater than 1.5 per spindle indicate that the write times for that hard disk are insufficient.

Processor time SQL Server process Average values greater than 80 percent indicate that processor capacity on the database server is insufficient.

Processor time Total Shows the percentage of elapsed time that this thread used the processor to execute instructions.

Memory utilization

Total Shows the average utilization of system memory.

Related resources

Top node for Capacity in library

http://technet.microsoft.com/en-us/library/cc262971(Office.14).aspx

Overview http://technet.microsoft.com/en-us/library/cc261700(Office.14).aspx

Limits http://technet.microsoft.com/en-us/library/cc262787(Office.14).aspx

Team Documents http://technet.microsoft.com/en-us/library/ff608068(office.14).aspx




http://technet.microsoft.com/en-us/library/ff608068(office.14).aspx