Category list

Conclusion

Now that you understand the groundwork for .NET and our analysis methodology, we will present an in depth approach to performance analysis planning in Chapter 2. We will detail how to analyze site traffic in order to characterize the site average and peak loads. This will offer the foundation for setting reasonable and attainable performance targets in the analysis phase.

Chapter 2

Preparing and Planning for the Performance Test

Often Web applications fail to meet their customers needs and expectations. When a Web application generates errors, has poor response times, or is unavailable, customers can easily become frustrated. If your performance test procedure or methodology is not well thought out and properly planned, the odds of a successful Web application launch are significantly reduced. This chapter identifies the key processes and planning required before you execute a single performance test. By following these steps you will enhance your odds of executing an effective Web application performance test. These steps include identifying performance goals, creating a user activity profile, and defining the key metrics to monitor and analyze when creating a performance test plan.

NOTE
We have found that many performance test projects fail because testing begins too late in the Web application development cycle or have requirements that are too complex to complete in the allotted time. Focus on the key elements of your Web application and on user scenarios that will occur most often. If time permits , you can always go back and execute a performance test on the other features that are rarely used.

Identifying Performance Goals

High-level performance goals are critical to ensure your Web application meets or exceeds current or future projected requirements. The best approach is to use historical data or extensive marketing research. Examples of poor planning are e-commerce Web applications that can’t handle the peak holiday shopping rush. Every year the media publicizes Web applications that cannot procure all their orders, suffer from slow user response times, Web server error messages, or system downtime. This costs not only in terms of lost sales, but in bad press as well.

High-level performance requirements can be broken down into the following three basic categories:

Response time acceptability
Throughput and concurrent user goals
Future performance growth requirements

Response Time Acceptability Goals and Targets

By researching how and where your users will connect to your Web application, you can build a table similar to Table 2-1 to show the connection speeds and latency of your potential customers. This can help you determine an acceptable amount of time it can take to load each page of your Web application.

Table 2-1. Predicted Connection Speeds
User	Worst Connection	Average Connection	Best Connection
Line Speed	28.8-kbps modem	256-kbps DSL	1.5-mbps T1
Latency	1000 milliseconds	100 milliseconds	50 milliseconds

Once you have identified how your user base will access your Web application, you can determine your response time acceptability targets. These targets define how long it can acceptably take for user scenarios or content to load on various connections. For example, with all things being equal, a 70-kilobyte page will obviously load faster on a 256-kbps DSL connection than on a 28.8-kbps modem connection. The response time acceptability for your 28.8-kbps modem might be 15 seconds, while the 256-kbps DSL connection might be significantly less, at 5 seconds. Response time acceptability targets are useful when you perform an application network analysis, which is discussed in detail in Chapter 5. The purpose of conducting the application network analysis is to perform response time predictions at various connection speeds and latencies, determine the amount of data transferred between each tier , and determine how many network round trips occur with each step of a user scenario. If you do not have historical data or projections for potential customer connection speeds and latencies we recommend using worst-case estimates. The data in Table 2-1 represents worst, average, and best connections of typical end-user Internet connection speeds.

Throughput Goals and Concurrent User Targets

Answering the following questions will help to determine throughput goals and concurrent user targets:

How many concurrent users do we currently sustain or expect in a given time period?
What actions does a typical user perform on our Web application and which pages receive the most page views in a given time period?
How many user scenarios will my Web application process in a given time period?

The best place to gather this information is from historical data, which can be found in Web server log files, System Monitor data, and by monitoring database activity. If you are launching a new Web application, you may need to perform marketing research analysis for anticipated throughput and concurrent user targets. Historical production data or marketing research is useful to ensure you execute the performance tests using the right concurrent user levels. If, after you complete your performance tests, your Web application meets your throughput and concurrent usage requirements, you can continue adding load until your Web application either reaches a bottleneck or achieves maximum throughput. Table 2-2 shows predicted throughput goals and concurrent user profile expectation for the IBuySpy sample Web application. Using the information in this table, a performance test script can be created to mimic anticipated load on the Web application. The ratio column represents the percentage that this particular user operation is executed with respect to all the user operations. The anticipated load per hour is taken from historical data, which will be illustrated in the next section of this chapter and represents how many times per hour this particular user operation typically occurs.

Table 2-2. Throughput and Concurrent User Targets
User Operations	Ratio	Anticipated Load per hour
Basic Search	14%	1,400
Browse for Product	62%	6,200
Add to Cart	10%	1,000
Login and Checkout	7%	700
Register and Checkout	7%	700
Total	100%	10,000

Performance Growth Analysis

A performance growth analysis is required if your Web application user base is expected to grow over a given time period. You need to account for user growth when performance testing. Performance testing and tuning your Web application after your development cycle is complete will cost more in time and money, when compared to fixing your performance problems during the software development life cycle (SDLC). In the real world example in Chapter 1, expenses incurred by finding and fixing their Web application performance issues after the SDLC included: lost marketing revenues due to bad press, lost users who are not patient enough to wait for slow page views, and test and development labor costs spent troubleshooting and fixing the issue. Taking a little extra time during the performance test cycle to populate your database with additional data to see how it will perform when it is larger will save you money in the long run. Also, execute the stress test with more load and with higher levels of concurrent users to predict future bottlenecks. By fixing these issues ahead of your growth curve, you will reduce your performance testing and tuning needs in the immediate future and ultimately provide your users with a better experience.

TIP
One tip for preloading your database with extra orders, baskets , and so on is to run your performance test script for a sustained period of time (possibly a few days) before executing your actual performance analysis. Your Web application UI will ensure data is accurately added to your system. The fastest way to pre-populate your database is to have the database developer create and test data via SQL scripts. However, one common mistake when pre-populating a database with SQL scripts is to miss certain tables that are updated through the UI of a Web application. The point is to ensure that you populate your database accurately; otherwise , it will adversely affect your performance test results.

The easiest way to determine the growth capacity of your Web application is to calculate the increase in volume you are currently experiencing over a specific period of time. For example, assume your user base is growing at a rate of 10 percent per month. Table 2-3 illustrates an anticipated growth plan that can be used when performing your stress tests. This assumes your Web application is currently seeing 10,000 users per day and will grow at a rate of 10 percent per month. When determining your growth rate, don’t forget to account for special promotions that may increase traffic to your Web application.

Table 2-3. Future Growth Profile
Time Period	Users Per Day
Current	10,000 per day
Three months out	13,310 per day
Six months out	16,104 per day
Nine months out	21,434 per day
Twelve months out	28,529 per day

Flylib.com

Category list

Conclusion

Similar products