An Introduction to the TriMont Web Site

The new Java-based web site contains basic e-Commerce features such as the following:

• View items by category

• Various search functions

• Shopping cart

• Order status

• Account information

The new site has some features the TriMont team hopes will give them an edge over their competition:

• Boat Selector ” Select your favorite river, and this feature shows you a selection of boats suited for that river 's specific conditions.

• River Conditions applet ” Viewer specifies a list of rivers, and the applet displays the current conditions at those locations (river height, temperature, wind speed, and so on).

Site Requirements

Here are a few site requirements the TriMont team shares on your first consulting visit:

• Based on the traffic to their existing web site, they expect the new site to get about 100,000 users per day (the clothing and gourmet cookware generate a lot of interest in the site) during the peak days of the Christmas shopping season .

• They estimate the user visit to last seven minutes.

• TriMont hopes 5% of users actually make purchases.

• Response time for any page must be under five seconds, even at peak.

• They expect significant activity on the new site 24 hours a day.

Initial Assessment

What do you know about the site at this point, and what do you need to create a more complete plan? Surprisingly, even at this point, you know a great deal about the site's key performance stress points.

The e-Commerce Profile

The TriMont Mountain site fits the pattern of the classic e-Commerce site covered in Chapter 5. You assume the TriMont performance test needs to focus on the following performance pressure points:

• Concurrent users: Notice that TriMont expects the average user to remain on the site seven minutes. Again, e-Commerce sites often experience user visits of several minutes as users look at items in the online catalog. This is an average, and some of their users visit for much longer. The company plans to keep its HTTP session timeout at 30 minutes, allowing customers to browse leisurely without risking session loss.

• Transaction rate: During peak season, e-Commerce sites serve up lots of pages to their visitors . The site needs to support this high transaction rate while satisfying the maximum response time requirement. (The TriMont team, as we know, expects 100,000 user visits per day. This results, as we'll see later, in many more page requests during the peak day.)

• Response time: As with all web sites, response time is critical for e-Commerce sites. If visitors become frustrated by slow response time, they leave. This costs the company business and goodwill with their customers. Again, TriMont wants to keep response time under five seconds, even during peak loading.

Also, as we discussed in Chapter 5, e-Commerce sites typically generate large pages, which usually contain lots of gifs, jpegs, and other static elements.

Peak Site Users

TriMont doesn't provide much detailed information about its peak loading. At this point, we recommend using the information you have to generate some rough estimates. This first estimate gives you a frame of reference for any other numbers you might receive during the planning phase. For example, you often receive peak load estimates from different sources inside the company. The marketing team might develop one projection for the peak hour , while the web master for the existing CGI web site might produce completely different numbers . A rough estimate gives you a starting point for comparing disparate requirements.

We'll fill in the Capacity Sizing worksheet from Appendix A as we go along. Table 10.1 shows the data that is currently available.

Begin by obtaining a rough estimate of the peak load relative to the average daily load. For example, you might estimate the user arrival rate in the peak hour at five times the rate in an average hour:

 100,000 users/day / 8-hour day  3.5 users/second (average load) 3.5 users/sec * 5 (peak versus average load) = 17.5 users/second (peak adjusted) 

Normally we'd recommend a "three times" estimate for an e-Commerce peak hour. However, the previous TriMont web site experienced serious performance problems. The company wants to be very conservative with its estimates because of these problems and allow plenty of what seems to be excess capacity.

Notice also that the example uses 8 hours for the load distribution, not 24, despite the customer's stated expectations. Few web sites actually receive large volumes of traffic overnight. You need to confirm this with the customer at your planning meeting, but 8 hours results in a more conservative estimate. Given these assumptions, the example leads you to the following peak hour traffic:

 17.5 users/second * 60 seconds/minute * 60 minutes/hour = 63,000 users/hour 

Table 10.1. Capacity Sizing Worksheet, Initial Input Data

	Input Data (estimates)	Source of Data	Your Data
1.	Number of user visits (day)	Marketing team	100,000
Note, if you cannot estimate 2, provide estimates for 3 and 4 below.
2.	Percentage of daily users arriving in peak hour	Estimate	Unknown
Note, provide 3 and 4 below only if you did not know 2.
3.	Number of hours per day site is actively used (load distribution time)	Estimate provided by marketing team (when in doubt use 8 hours)	8 hr
4.	Peak load increase over normal hour	Estimate (typically between 3 and 5)	5
5 “7 must be provided to calculate throughput from user visits. (Items 6 and 7 appear in Table 10.3 .)
5.	Average user visit time	Marketing team	7 min

In other words, almost two- thirds of the daily traffic arrives during the peak hour. In our experience, this seems high for this type of site, but again, given the problems with the old site, this might be a reasonable peak estimate.

Using the peak users per hour, you next determine how many users are on the system during any seven-minute interval (this is the average user visit):

 17.5 users/second * 60 seconds/minute * 7 minutes (average user visit) = 7,350 users 

At the peak hour, you estimate the site contains about 7,350 concurrent users. Note this number does not account for HTTP session timeout. This merely tells us how many people interact with the system during the time of an average user visit. Table 10.2 shows the peak calculations using the worksheet.

Table 10.2. Capacity Sizing Worksheet, Peak Load Calculations

	Calculated Data	Equation	Total (per hr)	Total (per min)	Total (per sec)
If you have data for 3 and 4, use the following calculations
9.	Number of user visits adjusted for length of day	Number of user visits/Web site day Line 1 / Line 3	100,000 visits/day / 8 hr = 12,500 visits/hr	12,500 visits hr / 60 min = 210 visits/min	210 visits/min / 60 sec = 3.5 visits/sec
10.	Number of user visits adjusted for peak load	Number of user visits/day * Peak load factor Line 9 * Line 4	12,500 visits/hr * 5 peak adjustment = 63,000 visits/hr (peak)	1,050 visits/min (peak)	17.5 visits/sec (peak)
Do the following calculations. Use the value from line 8 (optional) or line 10.
11.	User arrival rate (new users per time unit)	User arrival rate = Line 8 or Line 10	63,000 visits/hr (peak)	1,050 visits/min (peak)	17.5 visits/sec (peak)
12.	Concurrent users	User arrival rate * User visit time Line 11 * Line 5	Not typically used	1,050 visits/min* 7 min = 7,350 concurrent users (peak)	Not typically used

Next Steps

You need additional information to build a good performance test with this customer. You make plans to visit the customer again to discuss the test plan with the team leaders and their management. Prior to your visit, you request the following information from the customer:

• The data you need for a network analysis

  • Typical outbound page size .

  • How many pages does the average user visit in seven minutes?

  • How big are other elements such as applets and JavaScript?

  • How frequently are these elements accessed?

  • Size of any other data moving across the network (for example, database transfers).

• Components

  • Does the application server vendor have any capacity estimates to help the customer select a server for the test?

  • A list of other components involved in the test (databases, HTTP servers, weather servers, shipping company servers, and so on).

  • How big are the databases involved? Where are they located? Is this a production database?

• Visit patterns

  • What do the users do on the site?

  • Can the customer provide a breakdown of the frequency of certain activities (for example, 75% browse, 2% check their order status, and so on).

  • How frequently is the applet requested ? How much traffic does it generate?

• Miscellaneous

  • Do they use HTTP sessions? How big are they?

  • Does the site use SSL? If so, list the functions covered by SSL.

  • What security functions does the site use? If they call an LDAP server on every request, this adds time and network traffic to our totals. (For the sake of simplicity, we did not add any security issues to the numbers in the case study.)

Also, now is a good time to discuss issues like high availability for the web site. Should you plan for session failover? What about redundant hardware and networks?