Estimate performance and capacity requirements for Web Content Management in SharePoint Server 2010

 

Applies to: SharePoint Server 2010

This article contains guidance on capacity management that is relevant to Microsoft SharePoint Server 2010 sites that have the Publishing Infrastructure enabled. This document is specific to SharePoint Server 2010, and the information that is discussed does not apply to SharePoint Foundation.

This article discusses the following scenarios:

• An Internet publishing site - a corporate presence site.

  This kind of site is published to the Internet and lets anonymous Internet users find information about a corporation. Sites such as these are branded and the content is tightly controlled.

• An intranet publishing site - an internal news site.

  This kind of site is published internally inside an organization. Its primary use is to share information with the authenticated users inside the organization. Information in the site might be managed tightly, or some areas might be less managed.

• An enterprise wiki - a knowledge repository.

  An enterprise wiki is a single-farm site that grows organically as contributors create new pages and link them to other pages that might or might not exist yet. Enterprise wikis are typically published internally inside an organization. This site enables people across a company or organization to capture and share knowledge by using a solution that is integrated into and enhanced by their SharePoint environment.

After reading this document, you will understand the following concepts:

• The key metric (throughput) that you should maximize to support lots of read operations.

• Various potential bottlenecks that are relevant to a Web Content Management SharePoint Server 2010 deployment.

• The importance of the output cache in maximizing throughput.

• The effect of write operations on the end-user read experience.

In this article:

• Prerequisite information

• Test details and approach

• Web Content Management deployments

• What to optimize

• Test results and recommendations

• About the authors

Prerequisite information

Before you read this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management. The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document.

For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in this article, see the following documents:

• Capacity management and sizing for SharePoint Server 2010

• Performance and capacity technical case studies (SharePoint Server 2010)

Test details and approach

In each test, variables that might be present in the real world have been abstracted to show specific recommendations. Therefore, it is very important to test and monitor in your own environment to make sure that you have scaled correctly to meet the request volume that you expect. To learn more about capacity management concepts, you can refer to Capacity management and sizing overview for SharePoint Server 2010.

This article discusses performance with Site Collection Features, SharePoint Server Publishing Infrastructure, and Output caching. These features are available only when the SharePoint Server Publishing Infrastructure is enabled. By default, Publishing Portals have this feature enabled.

Dataset

The tests were conducted by using a dataset that shares common characteristics with actual Web Content Management deployments. Although load was constant, different pages were requested. The following table describes the dataset that was used for these tests.

Dataset

Object	Publishing site
Size of content databases	2.63 GB
Number of content databases	1
Number of site collections	1
Number of Web applications	1
Number of sites	50
Number of pages	20,000 pages, divided into 20 folders that have 1,000 pages each
Composition of pages	Article pages in basic HTML, with references to two images
Page size	42 KB uncompressed; 12 KB compressed
Images	3,000 at 30 KB to 1.3 MB each

We recommend configuring Internet Information Services (IIS) to always compress files instead of the default setting to dynamically compress files. When dynamic compression is enabled, IIS compresses pages until CPU utilization exceeds a certain threshold, at which point IIS ceases to compress pages until utilization drops under the threshold. The tests in this article were conducted with compression always on.

This test dataset used only default SharePoint Server 2010 features that are included with the product. Your site probably includes customizations in addition to these basic features. Therefore, it is important to test the performance of your own solution.

Hardware

The number of Web servers in the farm varied by test. But each had identical hardware. The following table describes the Web and application server hardware that was used during these tests.

Hardware specifications for application servers and Web servers

	Web server
Processors	2 quad core at 2.33 GHz
RAM	8 GB
Operating system	Windows Server 2008, 64 bit
Size of the SharePoint drive	300 GB
Number of network adapters	2
Network adapter speed	1 gigabit
Authentication	Windows Basic
Load balancer type	Hardware load balancing
Software version	SharePoint Server 2010 (pre-release version)
Services running locally	Central Administration Microsoft SharePoint Foundation Incoming E-Mail Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service

The following table describes the database server hardware that was used during these tests.

Hardware specifications for database servers

	Database server
Processors	4 quad core at 3.19 GHz
RAM	16 GB
Operating system	Windows Server 2008, 64 bit
Storage	15 disks of 300 GB @ 15,000 RPM
Number of network adapters	2
Network adapter speed	1 gigabit
Authentication	NTLM
Software version	Microsoft SQL Server 2008

Glossary

There are some specialized terms that you will encounter in this document. Here are some key terms and their definitions:

• RPS   Requests per second. The number of requests received by a farm or server in one second. This is a common measurement of server and farm load.

  Note that requests differ from page loads; each page contains several components, each of which creates one or more requests when the page is loaded. Therefore, one page load creates several requests. Typically, authentication checks and events that use insignificant resources are not counted in RPS measurements.

• Green Zone   This is the state at which the server can maintain the following set of criteria:

  • The server-side latency for at least 75 percent of the requests is less than 1 second.

  • All servers have a CPU utilization of less than 50 percent.

  • Failure rate is less than 0.01 percent.

Web Content Management deployments

There are two models by which content is authored in SharePoint publishing sites that can affect your choice of server farm topology.

In the author-in-place model, a single site collection is shared by authors and visitors. Authors can create and update content at any time, which leads to variable distributions of read and write operations throughout a given day. This server farm typically experiences lots of reads and a moderate number of writes.

The following diagram shows how authoring-in-place works from a topology perspective.

In the content deployment model, multiple site collections separately and exclusively support content authoring and publishing. Content is created and updated in the authoring environment and then deployed to the publishing environment on a scheduled basis to be read by visitors. The publishing environment primarily serves read requests except when content is being deployed from the authoring environment. Unlike the author-in-place model, the server load that is exerted by content deployment can be adjusted to scheduled intervals.

The following diagram shows how content deployment works from a topology perspective.

These content authoring models are mutually exclusive.

Although Internet publishing sites and intranet publishing sites can use either the author-in-place model or the content deployment model, enterprise wikis work best with the author-in-place model. An enterprise wiki typically experiences a larger volume of write operations relative to read operations because a larger proportion of users can edit pages. Enterprise wiki pages differ from publishing article pages and exhibit different performance characteristics.

What to optimize

This section discusses information for optimizing your Web Content Management environment. Optimizing the environment includes understanding how to manage throughput, bottlenecks, and caching.

In this section:

• Throughput is the key metric

• Bottlenecks and remediation

• Caching helps

Throughput is the key metric

Throughput and response time are the most important metrics to optimize when you conduct capacity planning for a SharePoint Server 2010 Web Content Management deployment. Throughput is the number of operations that a server farm can perform per second, measured in requests per second (RPS).

Bottlenecks and remediation

A bottleneck is the system resource that, when it is used up, prevents the server farm from serving additional requests. The following diagram shows the elements of a server farm and the resources that can become bottlenecks and that should be monitored.

Web server CPU utilization

The Web server CPU should be the bottleneck of a well-tuned topology because it is the most easily scalable component. The load balancer routes requests among Web servers and ensures that no single server is significantly more used than its peers.

Although additional users can visit the site after Web server CPU utilization is fully used, the server response time that these users experience increases. This behavior is useful for managing spikes in request volume. However, sustained load beyond a server farm’s capacity eventually results in a backlog of requests that is large enough to exceed the waiting requests threshold. At this point, Web servers throttle requests and respond with HTTP error 503. In the following illustration, server response time decreases after the waiting requests threshold is met because only HTTP errors are served.

The following changes are shown in this diagram:

1. Response time increases as Web server CPU utilization approaches 100 percent.

2. After the waiting requests threshold is exceeded, additional requests are served with errors.

Other bottlenecks

If the Web server CPU is not the bottleneck, the next items to investigate for bottlenecks are the farm topology, the farm configuration, or the content of the pages being served. Some potential bottlenecks in these elements include the following:

1. Network    In situations of high throughput, the network might be saturated either between the Web server and the database server or between the Web server and end users. To avoid this situation, we recommend that Web servers use dual gigabit network adapters.

2. Database server CPU    If the database server CPU becomes the bottleneck, adding Web servers to the server farm cannot increase the maximum throughput that the farm can support. A bottleneck with the database CPU but not with the Web server CPUs can reflect two situations:

   1. Poor cache settings or very slow pages, especially those that are not output cached. This is characterized by high database server CPU utilization but low or medium throughput and low or medium Web server utilization.

   2. The database server might have reached capacity for the throughput required for the farm. This is characterized by high Web server and database server CPU utilization at high throughput.

Caching helps

SharePoint Server 2010 uses three kinds of caching. The common goal of these caches is to improve efficiency by reducing calls to the database for data that is frequently requested. Subsequent requests for a page can be served from the cache on the Web server, which results in significantly reduced resource utilization on the Web servers and database servers.

The three kinds of caching are as follows:

• Output cache   This cache stores requested page content in the memory of the Web server. For more information about the output cache, see Output Caching and Cache Profiles (https://go.microsoft.com/fwlink/p/?LinkID=121543).

• Object cache   This cache stores SharePoint objects, such as Web and list item metadata, in the memory of the Web server. For more information about the object cache, see Object Caching (https://go.microsoft.com/fwlink/p/?LinkID=123948).

• Disk-based cache for Binary Large Objects (BLOBs)   This cache stores image, sound, video files, and other large binary files on disk. For more information about the BLOB cache, see Disk-Based Caching for Binary Large Objects (https://go.microsoft.com/fwlink/p/?LinkID=123947).

Each of these caches is important for sustaining high throughput. However, output caching has the largest effect and is discussed in detail throughout this article.

Test results and recommendations

This section discusses specific areas that were tested and provides recommendations that result from those tests.

In this section:

• Effect of enabling the output cache

• Anonymous users and authenticated users

• Scale-out characteristics of read and write operations

• Output cache caveats

• Effect of read volume on CPU and response time

• Effect of write operations on throughout

• Effect of content deployment

• Effect of database snapshot during content deployment export

• Content characteristics

Effect of enabling the output cache

The output cache is a valuable feature to use to optimize a SharePoint Server 2010 solution for lots of read operations.

For these tests, to determine maximum RPS, the number of active users making requests on the farm was increased until CPU utilization of either the database server or the Web servers reached 100 percent and became a bottleneck. The test was conducted on 1x1 (1 Web server and 1 database server), 2x1, 4x1, and 8x1 farm topologies to demonstrate the effect of scaling out the Web servers at different output cache hit ratios.

Output cache hit ratio

The output cache hit ratio is a measure of output cache hits to misses.

• A cache hit occurs when the cache receives a request for object data that is already stored in the cache.

• A cache miss occurs when a request is received for object data that is not stored in the cache. When a cache miss occurs, the cache will attempt to store the requested object data so that later requests for that data result in a cache hit.

There are several reasons why a page request might result in a cache miss.

• Pages that are configured not to use the output cache.

• Personalized pages, for example, pages that have data that is specific for the current user.

• First time browse per output cache variation key.

• First time browse after cached content has expired.

The following diagram shows the effect of output caching on peak throughput in farms ranging from one to four Web servers and one database server.

Note

The data point for maximum RPS on a 4x1 server farm with a 100 percent output cache hit ratio is extrapolated and was not actually observed. The server farm request volume reached the network bandwidth limit; that is, the data transfer rate approached 1 gigabit per second. In all cases, the Web server CPU utilization is 100 percent.

The following table lists the effects of output cache hit ratios on farm topologies ranging from one to four Web servers and one database server.

Effects of output cache hit ratio on different farm topologies

Output cache hit ratio	Measure	1x1	2x1	4x1
100%	Maximum RPS SQL Server CPU utilization	3,463 0%	7,331 0%	11,032 0%
95%	Maximum RPS SQL Server CPU utilization	2,137 5.93%	3,945 12.00%	5,937 21.80%
90%	Maximum RPS SQL Server CPU utilization	1,518 7.12%	2,864 14.40%	4,518 28.00%
50%	Maximum RPS SQL Server CPU utilization	459 9.86%	913 19.50%	1,596  42.00%
0%	Maximum RPS SQL Server CPU utilization	172 9.53%	339 19.00%	638 36.30%

Conclusions and recommendations for the effect of enabling the output cache

Higher output cache hit ratios yield significant increases in maximum RPS. Therefore, we recommend enabling output caching to optimize your SharePoint Server 2010 publishing solution. You can configure the output cache on the Output Cache Settings page for the site collection. For more information, see Configure page output cache settings for a site collection (https://go.microsoft.com/fwlink/p/?LinkId=205058) on the Office.Microsoft.com Web site.

In tests that had output caching enabled, the first request that cached a page was excluded; that is, a certain percentage of pages are already stored in the cache. When a user first requests a page that is not cached, the page is added to the cache. If the cache has reached or is approaching capacity, the cache trims the data that was least recently requested.

The 0 percent cache hit ratio simulates the short time in an environment during which the enabled output cache is being filled after it was flushed. For example, this is observed every day in a real-world environment when the application pool recycles. It is important to scale your hardware up or out appropriately to accommodate a situation in which there is a 0 percent cache hit ratio for the brief time between the application pool recycle and the next requesting and caching of pages. The 0 percent cache hit ratio also simulates an environment in which output caching is not enabled.

Anonymous users and authenticated users

The previous test assumes that all requests to the site are made by anonymous readers. However, in your site, some or all users might be authenticated. Examples of authenticated read scenarios include a corporate intranet publishing site and members-only content on an Internet site.

With output cache profiles, you can specify output cache behavior for authenticated users that differs from the behavior for anonymous users.

Cache profiles

Cache profiles aggregate settings that you can apply to pages, page items, content types, and levels of scale in a site deployment. A cache profile defines the following kinds of cache behavior:

• The length of time that items should be held in the cache.

• The security trimming policy.

• The expiration of settings, such as duration and changes.

• The variations of cached content, for example, based on user permission, user rights, and other custom variables.

Any change to a cache profile immediately affects all applicable content on the site. You can set different cache profiles for anonymous users and for authenticated users.

For anonymous users, the Public Internet (Purely Anonymous) output cache profile was used and for authenticated users, the Extranet (Published Site) output cache profile was used.

The following chart shows the effects of authenticated throughput on database server CPU utilization.

The authentication model was Windows Basic authentication. Although we do not recommend that you use Windows Basic authentication for Internet sites, this authentication method was selected to demonstrate a minimum overhead that is imposed by authentication. The size of this overhead varies by your specific authentication mechanism. When you are testing your deployment, make sure that you account for the effect of your authentication mechanism. For more information about the authentication mechanisms that are supported by SharePoint Server 2010, see Plan authentication methods (SharePoint Server 2010).

Conclusions and recommendations for anonymous users and authenticated users

Authenticated users experience lower RPS and less scale-out potential because the additional work of validating credentials exerts load on the database server. As demonstrated in the test results, the maximum RPS that is observed when users are authenticated is significantly lower than that of an anonymous access farm.

Scale-out characteristics of read and write operations

Our tests were constructed to record writes per hour. In this article, a write is defined as either the creation and check-in of a new Publishing Page or the editing and check-in of an existing Publishing Page.

For the following tests, readers were added to the system until Web server CPU utilization reached approximately 80-90 percent, and then write operations were performed in the environment by using artificial delay. The total writes per hour for the test was approximately 500. We used a 90 percent output cache hit ratio for all tests. We performed the same test on a 1x1, 2x1, and 4x1 farm and observed the Web server and SQL Server CPU usage in addition to the overall read throughput for each configuration. In addition, we tested an anonymous read-only configuration as a baseline, and we also tested a configuration with authenticated readers by using Windows Basic authentication.

Although the Web server CPU was fully utilized at 100 percent usage during the read-only scale-out tests, we held the Web server CPU between 80-90 percent for the scale-out tests with writes. This was done to leave room for additional CPU utilization when write activity was being performed.

The following chart shows the overall read RPS that were observed during each test. The read RPS scales linearly as additional Web servers are added, even with write activity. However, there is an RPS loss when writes are incorporated.

Database server CPU usage increased as the number of Web servers increased. The following chart shows the growth pattern of SQL Server CPU usage in the various configurations. As observed in the Anonymous users and authenticated users section earlier in this article, authentication affects database server CPU utilization, and this becomes more pronounced as write activity is added (which also affects database server CPU utilization).

The extrapolated trend in SQL Server usage demonstrates that SQL Server will become the bottleneck with six Web servers that have authenticated read requests. However, in the anonymous read case, scaling out to a larger number of Web servers is workable.

It is important to be aware that additional factors in a typical deployment affect the load on the database server, and these factors are important to account for when you are conducting capacity planning. To learn more about how to determine a green zone for typical database server CPU utilization, see Capacity management and sizing overview for SharePoint Server 2010.

Conclusions and recommendations for scale-out characteristics of read and write operations

Our data shows that scaling out the number of Web servers is an effective strategy for increasing throughput if the database server does not become the bottleneck. On average, the anonymous read/authenticated writes test mix exerted a 52 percent increase in Web server CPU utilization compared to an anonymous read/no writes test mix. In addition, authenticated reads add a large additional SQL Server load, because each request incurs additional authentication checks, which requires a round trip to SQL Server.

The following chart shows the effect of throughput on database server CPU utilization.

Output cache caveats

If the only concern in capacity planning were to maximize RPS, these tests would suggest that the optimal cache hit ratio is 100 percent. However, it might not be workable or desirable to enable output caching of any or all pages because of data freshness requirements or memory constraints.

Data freshness

Data that is served from the output cache might not contain recent updates that have been made to the original content. In the source of content deployment or (for authenticated authors) in an author-in-production scenario, authors might want to see the most recent changes immediately after they update existing content.

This is generally eased by setting the Duration property in the cache profile, which specifies how long a cached page persists in the output cache before it expires. When a page expires, it is removed from the cache and a later request results in a cache miss that refreshes the page content.

The Check for Changes cache profile property can also be set so that the server compares the time at which a page was cached with the time at which content was last modified in a site collection. A request for a page that has unmatched time stamps causes cache invalidation for all pages in the site collection. Because the Check for Changes property affects all pages in a site collection, we recommend enabling this option only if there is an authenticated author-in-place solution that is infrequently updated and basically static. Combining this option with a long duration enables all pages to be served from the cache until an update is made to the site.

By default, the Check for Changes property is not enabled. This means that the Web server serves data from the output cache in response to requests for a page that has not yet expired, regardless of whether the underlying, original ASPX page was modified.

In this test, conducted on a 1x1 server farm, all variables are the same as in the tests in the Scale-out characteristics of read and write operations section except for the Check for Changes property. When the Check for Changes property is turned on, the cache is flushed more often, which results in a lower output cache hit ratio.

The following chart shows the effect of the Check for Changes property on throughput.

We recommend avoiding the Check for Changes output cache profile property except in specific cases. A site that uses the author-in-place model and experiences infrequent changes in content might benefit from this setting for authenticated users together with a long cache duration, but other kinds of sites will most likely have a degradation in RPS.

Depending on your requirements, you might want time-sensitive content to go live instantly or faster than the default settings allow for. In this case, you should decrease the duration or not enable output caching.

Conclusions and recommendations for output cache caveats

Output caching does not solve all the problems that are related to capacity management. There are some situations in which output caching is unsuitable, and you should consider these when you enable the output cache and configure output cache profiles.

Effect of read volume on CPU and response time

This test was conducted on a 1x1 farm with anonymous access and output caching enabled.

The following chart shows the effect of read volume on CPU and response time.

Conclusions and recommendations for effect of read volume on CPU and response time

As discussed in the Bottlenecks and remediation section, server response time will stay generally constant until the Web server receives sufficient request volume to fully use its CPU. As Web server CPU is fully utilized, response time will increase significantly. However, the server farm will still be able to handle some additional request volume.

Effect of write operations on throughout

The ratio of creation to editing operations is distributed evenly through the course of the tests. Writes per hour values were tested up to approximately 500, because creating or editing more than 500 pages per hour is outside the range which most SharePoint deployments would operate. The test did not cover automated processes, such as content deployment, which is discussed in the Effect of content deployment section. These create and edit operations might result in multiple SQL Server operations. Therefore, it is important to be aware that the writes that are measured in these tests are not at the SQL Server level, but instead represent what a user would consider a write operation. All RPS versus writes per hour tests were conducted on a 1x1 farm.

We first added read operations to the test until Web server CPU was between 60 and 80 percent to leave a buffer for traffic spikes, and we maintained this average utilization level throughout the course of the test. We then introduced writes by using an artificial delay to control the number of write operations. However, there were spikes of increased Web server and SQL Server CPU usage while the writes were occurring. Some of these spikes for some cache hit ratios exceeded the threshold for ordinary operation as shown in the following chart, although the average stayed within the range of ordinary operation.

As shown in the previous chart, there is a minor reduction in throughput as writes are added to the environment. The graph demonstrates the change in throughput between a read-only scenario and read operations during approximately 500 writes per hour. Two data points were recorded for each output cache hit ratio. Therefore, the relationship between data points is not necessarily linear.

The percentage reduction is more pronounced for lower cache hit ratios, as shown in the following chart. Overall read RPS remains largely dependent on the cache hit ratio, regardless of the writes.

The following chart demonstrates that the database server CPU utilization did not increase appreciably when writes were added to the system. Note that the vertical scale is from 0 to10 percent of CPU capacity.

Additional SQL Server load was observed during the write operations, which is expected. However, the largest increase was an additional 2.06 percent, which is insignificant. Average database server CPU utilization stayed lower than 10 percent throughout all tests. This test was performed on a 1x1 farm. Database server CPU usage will increase as the number of Web servers is scaled out. This is discussed more in Scale-out characteristics of read and write operations.

Web server CPU utilization was also measured during the tests. The following chart demonstrates that average Web server CPU usage remained in the 60-80 percent range throughout the course of the tests, even as the writes per hour approached 500.

However, the actual measured CPU utilization spikes when the writes occur, as shown in in the following chart. In general, these CPU spikes do not represent a problem. The goal of the green zone is to provide CPU head room to absorb some spikes in CPU load. Also, as additional Web servers are added, the effect of the spikes will be distributed across these servers so that the effect on a single Web server CPU will be lessened. However, you should know that such spikes would be expected in a real deployment; write activity is not uniformly distributed, although it does generally occur in bursts.

A 90 percent cache hit ratio is very low for a typical deployment. Most SharePoint Server 2010 deployments with lots of read operations will have an output cache hit ratio of 95 percent or more.

Conclusions and recommendations for effect of write operations on throughput

The data that is presented indicates that write operations will not have a large adverse effect on the overall throughput of the system for readers. You should recognize that write activity can cause spikes in CPU usage and you should plan your typical configuration to expect these spikes. A strategy for leveling these spikes is to scale out to multiple Web servers. This has two advantages:

• It spreads out the write load to multiple Web servers, which smoothes the overall spikes.

• It provides increased read RPS, especially at high output cache hit ratios.

Effect of content deployment

An alternative to the author-in-place model, which uses a single environment for editing and reading, is to split the single environment into two separate environments — an authoring environment and a production environment — and to use content deployment to copy content from the authoring environment to the production environment.

In this configuration, the production environment ranges from little write activity to no write activity, except when content deployment is importing content. For these tests, reads were added until the Web server CPU usage entered the 70-80 percent range. The content deployment job then exported 10 sites that have 500 pages each from the authoring site collection as a package and imported this package into the publishing site collection. The size of the deployed package is larger than what is typically observed in real-world environments in order to sufficiently extend the duration of the content deployment job to see test results. For additional information about characteristics of the deployed content, see the Dataset section.

When export was complete, we imported the content into a separate site collection and measured the application server and SQL Server load, in addition to the throughput, while import was in progress. The import test was conducted for several different output cache hit ratios.

The key observation is that import has only a minor effect on overall read RPS, as shown in the following chart. We also observed that import had no significant effect on the Web server CPU utilization, as shown in the following tables, regardless of cache hit ratio. However, there was a more noticeable effect on SQL Server CPU, shown in the following chart. This is expected, because the database server will experience additional load while content is imported in it. However, the SQL Server CPU stayed lower than 12 percent usage at all cache hit ratios tested, even during import.

The following tables show the effect of content deployment import on Web server and database server CPU utilization.

Effect of content deployment import on Web server CPU utilization

Cache hit	100%	99%	98%	95%	90%	50%	0%
Baseline	72.32%	73.26%	71.28%	73.53%	71.79%	68.05%	63.97%
With import	70.93%	74.45%	69.56%	74.12%	70.95%	67.93%	63.94%

Effect of content deployment import on database server CPU utilization

Cache hit	100%	99%	98%	95%	90%	50%	0%
Baseline	1.19%	1.64%	2.01%	3.00%	3.73%	5.40%	6.82%
With import	6.03%	6.82%	6.97%	7.96%	8.52%	10.29%	10.56%

Conclusions and recommendations for effect of content deployment

The results from our tests show that performing content deployment operations during ordinary site operations does not pose a significant performance concern. These results show that it is not strictly necessary to deploy content during low-traffic periods to minimize the effect of the operation on overall performance and that deployment times can be driven primarily by business needs instead of performance requirements.

Effect of database snapshot during content deployment export

In SharePoint Server 2010, content deployment can be configured to create a snapshot of the source content database before exporting content from it. This effectively shields the export process from any authoring activity that might be occurring while the export happens. However, snapshots can affect the write performance of the database server, because the snapshot acts as a multiplier for the writes. For example, if you have two snapshots of a source database, and then you write to the source database, the database server copies the existing data to each snapshot, and then it writes the new data into the source database. This means that a single write to the source database incurs three actual writes: one to the source database, and an additional one for each database snapshot.

To determine the effect of a snapshot on the authoring environment, we measured the write RPS, response time, and the CPU utilization of the Web servers, database server, and application server during an export operation while write activity was also occurring. The following tables display the results.

Effect of database snapshots during content deployment

Metric	4 WPH - No snapshots	4 WPH - With snapshots
Write RPS	0.2	0.16
Response time	0.13	0.15
Web server CPU %	0.42%	0.27%
Application server CPU%	8.67%	8.98%
Database server CPU %	3.34%	2.41%

Effect of database snapshots during content deployment

Metric	8 WPH - No snapshots	8 WPH - With snapshots
Write RPS	0.44	0.44
Response time	0.13	0.13
Web server CPU %	0.61%	0.73%
Application server CPU%	14.6%	12%
Database server CPU %	7.04%	7.86%

Conclusions and recommendations for effect of database snapshot during content deployment export

The results of our tests showed no significant effect on any measured data points with database snapshots. All variance that was recorded was within the margin of error. This confirms that database snapshots can be used without strong performance considerations.

Content characteristics

The tests were conducted on a single dataset that was created to answer a specific set of questions. Your dataset will differ and will change over time. This section investigates how content characteristics, such as the number of pages in the page library and the features that are included on pages, can inform capacity management decisions.

Number of pages

Maximum RPS across many page library sizes was tested. This test was conducted on a 4x1 topology with output caching disabled and with anonymous access. All pages were 42 KB uncompressed, 12 KB compressed. The following table shows the test results.

Effect of library page count on RPS

Number of pages	3	1,000	20,000
Maximum RPS	860	801	790

Increasing the number of pages to 20,000 did not have a significant effect on maximum RPS.

Multivalued lookup fields

A multivalued lookup field is a column in a list that references one or more items in another list, such as columns that use enterprise managed metadata. These fields are generally used as search keywords for a page and are not necessarily rendered. In some cases, for example enterprise wikis, it makes sense to render these field values into the contents of pages. For instance, pages might be filed into categories when they are created (for example, World News, Human Interest, and Sports on a news site) and the master page includes a placeholder that will show the user which categories the page was tagged with.

Multivalued lookup fields cause more data to be fetched every time a page is requested. Therefore, having many multivalued lookup fields on a page can affect performance.

The following chart shows the effect of multivalued lookup fields on throughput.

The following chart shows the effect of multivalued lookup fields on farm resource utilization.

Maximum RPS degradation occurs as the number of multivalued lookup fields increases due to the effect on the network between the Web server and the database server.

Effect of usage reporting

Usage reporting is a service that helps administrators monitor statistics about the use of their sites. For more information about usage reporting, see Configure usage and health data collection (SharePoint Server 2010).

We tested the effect of usage reporting timer jobs on maximum RPS on a 1x1 farm. The following table describes the results.

Effect of usage logging on performance (in RPS)

	Usage DB on	Usage DB off	Difference
Output cache on	3,459	3,463	4
Output cache off	629	638	9

The results show that enabling usage logging does not significantly affect RPS in a read-only scenario.

About the authors

Joshua Stickler is a Program Manager for SharePoint Server 2010 at Microsoft.

Tyler Butler is a Program Manager for SharePoint Server 2010 at Microsoft.

Zhi Liu is a Software Development Engineer in Test for SharePoint Server 2010 at Microsoft.

Cheuk Dong is a Software Development Engineer in Test for SharePoint Server 2010 at Microsoft.

Philippe Flamm is a Software Development Engineer in Test for SharePoint Server 2010 at Microsoft.