Performance Testing

This section discusses how you can hunt down any potential problems. Also, as previously discussed, performance testing will be necessary if you want to draft realistic performance goals.

Ideally, you will include performance testing in the development of each component within your site. Whether it is your personalization code or your navigation, you should test it to see if it performs well enough to be included in the final version of your site.

Performance Counters

In the area of performance testing, the best new feature of CMS 2002 is the performance counters. Performance counters allow you to monitor various values as you run your performance tests. Although these performance counters are not the most useful ones for calculating your performance numbers, they are very useful when you are diagnosing problems.

Table 35-1 shows the complete list of performance counters provided in MCMS 2002.

For more information about how to set up and use performance counters, refer to MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconmonitoringaspnetapplicationperformance.asp). You can also refer to the CMS help topic "Measuring and Testing Site Performance" for more information about CMS-specific considerations.

Table 35-1. Performance Counters

Counter	Counts	Description
Active Enterprise (AE) Node objects	Number of active MCMS COM objects on the server	These are the COM nodes created as each request is processed. Each request will generate many COM objects in the AEServer object, which are then destroyed as the processing completes. This counter is a snapshot of the number of COM objects active at any one time and is a reflection of the amount of processing activity within the MCMS server. In itself this does not provide a direct gauge of performance;however, high values would demonstrate a very active MCMS site. If the site is underperforming, this value can be decreased by using techniques such as caching the navigation controls, which in turn could improve performance.
AE Node objects created/sec	Number of AE Node objects created per second	As above, but this provides the average activity over time.
Guest sessions	Number of guest sessions on the server	This is the number of current connections to the MCMS server that are authenticated as a Guest user. This is more for informational purposes than to adjust performance, although it could be used to identify peaks of activity.
Guest sessions opened/sec	Number of guest sessions opened per second	As above, but this provides the average activity over time.
Authenticated sessions	Number of authenticated sessions connected to server	This is the number of current authenticated connections to the MCMS server. This is more for informational purposes than to adjust performance, although it could be used to identify peaks of activity.
Authenticated sessions opened/sec	Number of authenticated sessions opened per second	As above, but this provides the average activity over time.
Edit sessions	Authoring or development sessions connected to server	This is the number of current authenticated connections to the MCMS server that are in Edit mode. This is more for informational purposes than to adjust performance, although it could be used to identify peaks of activity. Edit activity on an MCMS server can have a significant impact on performance.
Edit sessions opened/sec	Number of authoring or development sessions opened sessions opened second	As above, but this provides the average activity over time.
ISAPI sessions	Number of Internet Server API (ISAPI) sessions opened by server	Provides the number of connections currently in the MCMS ISAPI filter performing URL transformations. If you have a high number of these, it may mean that the URL transformation is taking a long time, which may be adjusted by increasing the node cache size.
ISAPI sessions opened/sec	Number of ISAPI sessions opened per second	Tells you how many connections are opened per second in the MCMS ISAPI filter. Provides the number of URL requests to MCMS per second.
Master cache nodes	Number of items in internal MCMS master cache	Number of nodes in master cache. This is limited by the node cache size set in the SCA. If this value is less than the setting in the SCA, then this is an indication that all requested MCMS nodes are currently cached. If this value is close to or above the value in the SCA, then this is an indication that the setting in the SCA is not high enough to allow all requested nodes to be cached.
Shared nodes	Number of items/nodes referenced by server, including master cache items	This value is related to the number of master cache nodes; however this value will reflect multiple versions (e.g., checked in and checked out) of the same master node.
Shared nodes created/sec	Shared nodes created per second	This is a reflection of the increase in size of the node cache as new nodes are cached. If the master node cache value is close to or above the value in the SCA and this value is high, then this is a clear indication that objects are being moved into and out of cache, which will lower performance.
Cache hits/sec	Rate of cache hits on master cache	A high value here relative to the following value implies an effective use of cache.
Cache misses/sec	Rate of cache misses on master cache	A high value here relative to the preceding value implies an inefficient cache setting.
Data access operations/sec	Number of data access operations executed per second	This is the count of accesses to the SQL Server database. A high value could imply one of several things: The node cache value may be too small; the resource cache may be too small; or there is a need to cache search results.
Exceptions thrown	Number of exceptions thrown by server	This is informational and provides a count of exceptions thrown. If this is increasing rapidly over time, it could indicate problems on the server or in the code base.
Number of MCMS connections	Number of open MCMS application connections	This is informational and provides an indication of the load on the MCMS server. It includes all current connections to the MCMS server at a point in time. It includes the ISAPI connections plus all other connections.

Measuring Performance

How you determine your performance numbers determines how realistic those numbers will be when you deploy your site to the Web.

There are three steps to creating a performance test. First, you need to create a realistic usage profile. Next, you create test scripts, and finally, you run your test scripts. The following subsections discuss each of these steps.

Step 1: Create a Usage Profile

Your usage profile will be used as the game plan for your stress testing. Without the profile, you cannot be sure that you are focusing on the right portions of your site. For example, you may have a section of your site that is used frequently but performs worse than the rest of the site. You will want to ensure that you address the performance issues for these pages. Usage profiles will be discussed in more detail later in this chapter.

For more information about a usage profile, refer to "Creating a Usage Profile for Site Capacity Planning" (http://go.microsoft.com/fwlink/?LinkId=9508).

Step 2: Create a Test Script

There are different tools that you can use to stress your site. The most popular tool is Microsoft Application Center Test (ACT). This tool is designed to simulate load on your Web site.

Once you have created a usage profile, you will have a good idea of the URLs that will get hit in each visit. Hitting these URLs with a stress tool will give you performance numbers for each visit. You can either record a test script or programmatically create a test script.

For more information about ACT, refer to this URL: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/act/htm/actml_main.asp.

Step 3: Use a Stress Tool to Run the Script against Your Site

Running the stress tool against your site will give you the opportunity to use performance counters. Which counters you record will depend upon your business needs, but typical Web site stress tests measure CPU usage and ASP.NET (or ASP) requests.

For more information about throughput, refer to "Understanding Performance Testing" (http://go.microsoft.com/fwlink/?LinkId=9511).

Usage Profiles

Creating realistic usage profiles is fundamental to effective performance testing. A usage profile is a representation of your site visitors' behavior while they are surfing your site.

Generally, usage profiles consist of the following information:

• Average session length of the user

• List of pages visited

• Total number of pages visited in a session

• Frequency at which each page is visited

You will not need to model all these parameters, but you will need to accurately model pages that are hit and the frequency with which they are hit.

Average Session Length

"Session" is a word that is far too overloaded. In the context of usage profiles, think of a session as a unique visit from a user. One user may have many unique visits to a site. As the user surfs around the site, their one session might involve hitting many pages. Within those pages are many elements that can access many files. For example, one site might contain pieces cached in memory or various images from your hard drive.

The average session length represents the average number of minutes from the start of a user's visit to the end of the visit. You will need to use your IIS logs to gather information about the length of each session.

Pages Visited

Page views define the way that users surf a Web site. You can check your IIS logs to see the URLs for the pages that are being accessed the most.

Number of Pages

Tracking the number of pages visited will allow you to create usage profiles that match your users. By looking at how many pages are surfed, you can create stress scripts that include the appropriate number of URLs.

If you have statistics for the average session length, you can use this number and the number of pages visited to calculate the frequency of page visits.

Frequency of Page Visits

This statistic is important because it indicates how quickly your users navigate through your site. If you have a lot of content on your pages, you may find that users spend some time before moving on to the next page. However, if your users click rapidly through pages, then you would want to consider this when creating your usage profiles.