Transaction Cost Analysis

The Transaction Cost Analysis methodology is used to provide mathematical calculations for capacity planning. You can also use TCA principles to find performance bottlenecks on your site. Each operation is isolated and examined. Remember that creating accurate usage profiles is the first step to successful TCA analysis.

The benefit of this paradigm is that you do not have to model your environment the same way that you would using the prototype modeling approach. TCA is far more granular and therefore more flexible. For example, it may allow you to test on hardware that is not the same as your performance environment. Furthermore, you will be able to modify things like your usage profiles without having to run any new tests.

Once you have initial values for your TCA analysis, you will be able to use them for future changes to your site. Rather than analyzing the entire site, you can focus purely on the sections that have changed.

For the purposes of this chapter, we are using the example of CPU utilization. However, the TCA principles can be applied to other costs. For example, you might want to analyze the performance of your SQL Server machine or the memory usage of your Web server.

For more information about the TCA methodology, refer to the following articles:

• "Using Transaction Cost Analysis for Site Capacity Planning," http://go.microsoft.com/fwlink/?LinkId=9509. This article provides a hands-on guide to using TCA. We highly recommend that you read this paper before you read the rest of this chapter.

• "Capacity Model for Internet Transactions," http://go.microsoft.com/fwlink/?LinkId=9507. This article provides an overview of the TCA methodology.

• CMS 2002 white paper "Transaction Cost Analysis and Capacity Planning for MCMS 2002."

Page Cost Strategy

This is the strategy that we will be exploring in this chapter. The reason that we will use this method is that it is the most reliable way to test the performance of a CMS site. Depending on your business and your site, you may decide to use one of the other strategies. But even if you do, page cost will be a useful test for you. Page cost is the easiest because the tests are straightforward. You use a stress tool and record the results of one page. There isn't much that can go wrong with this strategy.

Since you have already read the TCA paper listed earlier (you did read it, right?), you have seen the example of a site performing various "operations." In our discussion, you can equate these operations with page cost.

Using Page Cost to Test Your CMS Site

Based on the page types identified for the site, the following tables can be produced. These numbers are based on the fictitious BOTS Consulting site.

Each of these tables represents a page from the usage profile. After using the performance counters to gather the cost of each page, you then average out the cost and calculate the total cost of the site.

What we will now do is create three scripts that hit each page individually. The scripts will be executed such that the processor will be at or near 85% utilization. Keep in mind that most sites try to run their production machines at about 35% utilization. This allows them to scale to a peak load of three times the normal traffic. We are using 85% for these tests to check the performance near the peak load. Having run these scripts, we will record the CPU utilization and the pages-per-second throughput.

Tables 35-2 through 35-4 illustrate the CPU cost for each of the three pages that we are testing. We gather this information by running an ACT script against the URL for the page and then recording the Windows performance counter for CPU utilization.

Table 35-2. Page 1: Home Page

Measurement	Value
CPU usage	0.80 (MHz)
Throughput	100 (pages per second)

Table 35-3. Page 2: Case Study

Measurement	Value
CPU usage	0.85 (MHz)
Throughput	150 (pages per second)

Table 35-4. Page 3: Article

Measurement	Value
CPU usage	0.90 (MHz)
Throughput	200 (pages per second)

Calculating Users Based on CPU Capacity

Calculating the number of users that your site can support is one of the key aims of performance testing. In fact, this one measurement is often the catalyst for all performance testing. The formula for calculating CPU capacity is the number of processors multiplied by the megahertz rating of the CPU.

CPU capacity = (number of processors) x speed

The next number to calculate is the target CPU capacity. This will determine your goal for CPU capacity. You will need to determine what you think your target should be. A value of 80% is often used because it allows some room in case your usage spikes for some period of time. For example, if your site happened to be mentioned by some large news site, you might find that you need that extra 20% of capacity.

Target CPU capacity = CPU capacity x .80

It is then a simple matter to determine how many simultaneous users you are able to support on one machine.

User capacity = target CPU capacity / Web CPU cost per user

Cost Table for Pages

Once you have numbers for each page, you can create a table such as Table 35-5. For this example, we are using fictitious numbers for the BOTS Consulting site, with one 1,000MHz processor.

The total CPU cost for each page is calculated with this formula:

Total CPU cost = (CPU usage x number of processors x CPU speed)/requests per second

For example:

Page 1 total CPU cost = (0.01 x 1 x 1,000)/110 = 0.09

Using Usage Profiles for TCA

Now we know the cost of individual pages. Based on our usage profile, we can add in the page distribution numbers, shown in Table 35-6. This determines how much of the traffic we expect each page to carry.

For this example, we will continue to use fictitious numbers from performance testing on the BOTS Consulting site. We will use these numbers to demonstrate how to calculate the user capacity for a CMS site. We will also assume that the Web server has one 1,000MHz processor.

Table 35-5. Total CPU Cost for Each Page in the Profile

Pages	Requests per Second	CPU Usage (MHz)	Total CPU Cost (MHz/Request)
Page 1: Home Page	110	0.80	7.27
Page 2: Case Study	120	0.85	7.08
Page 3: Article	130	0.95	7.31

Table 35-6. Distribution of Traffic

Posting Operation	Distribution
Page 1	50%
Page 2	30%
Page 3	20%
Total	100%

Next we can take our numbers from the CPU cost table (Table 35-5) and add in the data about the distribution of the load (Table 35-6). This gives us the cost of the particular usage profile, shown in Table 35-7. Table 35-8 shows the result of calculating the pages-per-second cost of the distribution profile.

As we learned earlier in this chapter, once you have all this information, you can take your throughput and divide it by the number of clicks for each user. In this example, our site renders roughly 111 pages per second. If our users click 1 page per second, then we could support 111 concurrent users.

Remember that your usage profile could include the rate that your users are clicking through your site. If we found that our IIS logs indicated that the average session length was ten minutes and the average pages per session was 20, then the click rate would be 0.017 pages per second per user. Based on this rate, we could support 6,517 concurrent users (110.79 pages per second / 0.017 pages per second per user).

Now that you have these numbers for a 1,000MHz processor, you could change the processor power to 2,000MHz. Without running any new tests, you would know that you would be able to support 13,034 concurrent users. You could also alter your user profile distributions and calculate the resulting effect on your performance numbers. And finally, you could change the code on one page and then just test the new page. You would not have to run all the other page tests again.

Table 35-7. CPU Cost for Distribution Profile

Pages	Distribution Profile	CPU Cost for Profile
Home Page	50%	7.27 x 0.5 = 3.635
Case Study	30%	7.08 x 0.3 = 2.124
Article	20%	7.31 x 0.2 = 1.462
Total	100%	7.221

Table 35-8. CPU Cost of Profile

Server CPU	Target CPU	Web CPU Cost for Profile	Pages/Second for Profile
1,000	1,000 x .80 = 800	7.221	110.79