Measuring and Tuning Performance

Measuring and
Tuning Performance
This chapter covers
• Performance optimization
• Caching
• Balancing items in containers
• Using API searches efficiently
• Limiting the use of placeholders
• Site navigation considerations
• Capacity planning
• Analysis and general considerations
• Transactions
• Failure of criteria
• Building a test site
Microsoft Content Management Server provides tools to plan, analyze,
and test an MCMS Web site to optimize its performance and ensure that it
can meet the required load. Optimal performance is achieved through opti-
mization of caching, scaling, and tuning to eliminate throughput bottlenecks.
Data provided in this section have been compiled from tests and analy-
ses that Microsoft has performed using the Microsoft Web Application Stress
Tool (WAST) and the Transaction Cost Analysis (TCA) tool from the Microsoft
Commerce Server 2000 performance toolkit. WAST is a load-generation tool
and TCA acts as a WAST controller. This chapter presents Microsoft’s recom-
mendations for MCMS settings (primarily caching) that can be tuned to
increase site performance and ameliorate known performance limitations.
This chapter also covers site design considerations and capacity planning
at a high level.
CHAPTER 3
39
Performance Optimization
Optimal performance is primarily based on the speed at which a page is

served. Testing performance, therefore, requires projecting requests per
second. Throughput is measured as
• Pages per second: A page is what the user sees after making a request;
one page can contain many data (ASP) requests that a server must exe-
cute or redirect.
• ASP requests per second: Each ASP request can contain many Get
requests.
• Gets per second: Individual requests for objects such as images.
The number of concurrent users on the site also affects throughput.
Two methods to maximize performance seem to yield useful results:
• Tuning performance with configuration settings and fragment caching
• Careful planning of site content at designtime, such as containers,
searches, placeholders, and navigation
Caching
Microsoft recommends setting the system cache to a size large enough to
hold the bulk of your binary data. Make sure the maximum number of nodes
in the memory cache is sufficient to hold the most commonly accessed pages
on your site. Keep in mind that a single page may require many nodes to be
displayed, depending on such elements as navigation, page depth, and sib-
lings. Performance of Web entry points marked as read-only can also improve
10% on average (MCMS uses less script code to serve a read-only request
than read/write). Read-only and read/write entry points for the same site
may require different-sized caches.
Object retrieval directly from the Content Repository for every trans-
action often presents a bottleneck. To improve response time, MCMS provides
memory-object and file-system (disk) caches. The memory object cache
stores data relating to API objects (channels, placeholders, and so on) and
is queried when an object is requested. The file system cache stores binary
data—resources, such as graphics and templates.
Each page request requires rendering a number of COM objects (into

HTML), and each time, the objects are created and destroyed. Fragment
caching saves the output obtained from the first rendering into the cache.
The fragment is output immediately and is stored in the cache for future use,
with little overhead. Use fragment caching for guest access because it’s typi-
cally the most frequent during high loads. Fragment caching should not be
CHAPTER 3
■
MEASURING AND TUNING PERFORMANCE40
used during site design because new objects are constantly being created,
which causes the cache to flush. Also, because the number of concurrent
users designing site elements is usually lower than at runtime, there is little
to be gained. Fragment caching can also conflict with authenticated access.
Set Disk Cache Location
Use the MCMS SCA to set cache location by entering the location or navigat-
ing to the directory for the local disk cache.
■
Note
The SCA does not allow you to specify a different drive.
Task 3-1. Setting Cache Location
1. Launch the SCA (Content Management Server 2002 group). Select the Cache tab, and
then click Configure.
2. To set Local Disk Cache Location, type or browse to navigate to a directory.
3. Close the SCA.
Set Maximum Cache Size
Set the maximum size of the cache in megabytes (MB) using the SCA.
Task 3-2. Setting Cache Size
1. Launch the SCA, select the Cache tab, and click Configure.
2. In the Maximum Disk Cache Size section:
• Use Global Default: Use global maximum cache size.
• Set Global: Set maximum global cache size.

• Use Local Override: Use the local setting for maximum cache size.
• Current Override Value: Set local maximum cache size.
3. In the Maximum Nodes in Memory Cache section:
• Use Global Default: Use the global value for maximum number of nodes.
• Set Global: Set the global maximum number of nodes.
• Use Local Override: Use local setting for maximum number of nodes.
• Current Override Value: Enter local value for maximum number of nodes.
4. Save settings and close the SCA.
CHAPTER 3
■
MEASURING AND TUNING PERFORMANCE 41
Clear Memory Cache
Clear the memory cache to remove temporary files stored in memory.
Task 3-3. Clearing Memory Cache
1. Launch the SCA, select the Cache tab, and click Clear Memory Cache.
2. Click OK to clear the cache and close the SCA.
Balancing Items in Containers
If the number of items in any one container is too high, performance is
degraded (accessing a container instantiates all items in the container).
Although the maximum number is hardware dependent, Microsoft recom-
mends a maximum of 400 items per container. Distribute items over multiple
containers and you won’t exceed the maximum. The greater the number of
items, the more impact fragment caching has.
Using API Searches Efficiently
API searches may query the database, which may be loading the database. If
searching is slow, use SQL Server Query Analyzer to see how the database is
loaded during searches. Use searches sparingly and make use of fragment
caching. Use SQL Server Query Analyzer to monitor the database load and
query execution.
■

Note
For additional information about SQL Server Query Analyzer, refer to the MSDN
article at
/>en-us/qryanlzr/qryanlzr_1zqq.asp
.
Limiting the Use of Placeholders
A clear rule of thumb about response time is the more placeholders per page,
the longer the processing time. Placeholder collections are treated like other
MCMS collections (instantiates all placeholders per page).
■
Note
Best practice: Do not store metadata in a placeholder; instead, use custom
properties.
CHAPTER 3
■
MEASURING AND TUNING PERFORMANCE42
Site Navigation Considerations
One important feature of MCMS is dynamic navigation. MCMS generates a
page-centric navigation bar—a context-sensitive set of navigation links from
the rendered page to those around it. On frameless sites, dynamic navigation
is generated for every page request. Dynamic navigation is costly because it
touches many objects. If navigation is deep, performance will be adversely
affected.
■
Note
Best practice: To help offset this overload, use fragment caching.
Capacity Planning
The goal of capacity planning is to implement an installation that can han-
dle your site’s projected load. What is the business goal that you are trying
to achieve? What are users going to request and how many will visit the

site? What latency, in terms of response time, is acceptable? How many
contributors will be submitting content and under what conditions?
When you have finished your analysis, you should have the following
tasks completed:
• Map the workflow of your personnel to MCMS publishing workflow.
• Identify managerial, authoring, administrative, development, design,
review, and editorial roles.
• Assign development roles (moderator, resource manager, and template
designer).
• Define the automated publishing process (development, content contri-
bution, staging, testing, and production).
Don’t forget, administrators and content managers require training.
MCMS 2002 administrative and user tutorials are available in the MCMS 2002
documentation.
Capacity planning is also a dynamic activity; after your site is opera-
tional, monitoring performance helps you adjust to actual demand. In this
subsection, we’ll go over a capacity planning strategy that includes consider-
ing initial guidelines, testing the installation’s response to load, and making
long-term projections.
CHAPTER 3
■
MEASURING AND TUNING PERFORMANCE 43
Analysis and General Guidelines
Optimal performance of the MCMS installation depends on the Web server’s
and database server’s disk speed, RAM, and so on, as well as the general
throughput of the network connection. However, some logical areas need
examination as well:
• Runtime production server load
• Authentication
• Content contribution load (mix of designtime and runtime operations)

• Deployment options
Use the following list of general guidelines when determining capacity
planning for your site:
• Read-only sites are restricted to the Web server CPU; dynamic sites can
create loads on the local server and other servers that resolve placehold-
ers with content from the repository.
• Authoring makes up a very small percentage of a site’s traffic, even in
large sites.
• Deployments are database-, CPU-, and Web Server CPU–intensive.
Transactions
A clear understanding of planned targets is invaluable in creating a set of
transaction goals:
• Determine the business issue being addressed with this site.
• Talk to employees from different levels in the management hierarchy
about their job functions and departmental growth projections.
• Validate and compare your estimates against other industry figures
or other sites your company operates.
• Determine the anticipated user base.
• Review known industry results and traffic levels.
• For e-commerce sites, determine browse-to-buy and hits-before-
purchase ratios.
• Determine peak traffic volumes—what is the range between average
and peak traffic?
In your analysis of site requirements, you must first determine the type
of business that is being transacted. Follow-up questions will be easier to
CHAPTER 3
■
MEASURING AND TUNING PERFORMANCE44