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.
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.
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).
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:
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.
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.