Load test for your ASP program

Introduced

As we move from a traditional CS-structured application to a current popular web-space program, we find ourselves trying to keep up with growing testability requirements and performance requirements. One of the biggest challenges is how to determine how many users your program can support. How do you face this challenge? Setting clear performance goals and using the Web Stress test tool can be a good start.

This article will explain how to stress test your ASP program and will introduce Microsoft's Stress testing tool-Web application Stress Test Tool (WAS). In the next chapter, you'll learn the basics of stress testing, and you'll learn some of the necessary skills. , through these studies, you will be able to test and modify your program more effectively according to the results of the test.

Plot

Suppose you are going to publish an ASP program that is expected to be used by 1000 of users. You know clearly that your program can handle at least two concurrent users, because you and your partner can click on the ASP program all day without any problems. You are wondering whether two users can accurately reflect the compression capability of your program. Of course you can use standard test methods (publish your program and expect the best results), yet you decide to test your program's performance in advance. That's a good sign!

Test requirements

To better test your ASP program, you first need to decide how much pressure your program will need to face in the future. Simply put, the pressure or load can be broken down into the following numbers:

· Minimum number of users. (What is the minimum number of users of this program?) Usually this number can be daily or not weekly or monthly clicks-Of course you can also break down into a more manageable number-hourly traffic,

· Total number of concurrent users. (What is the worst-case situation at the highest peak?) Make a plan accordingly. Hope to work normally and effectively under pressure.

· Request Peak value. (How many ASP pages are needed per second?) This is perhaps the most important factor in measuring the ability of an ASP program to respond to user requests.

It is often difficult to determine the number of users and concurrent users for your program, and before your program is actually used. Especially network programs. Even LAN programs often face increased user problems, so accurate estimates of user volume will be difficult. When you don't know how to start, it's best to start with the basics:

Issues to consider on the Internet:

· Analyze your existing IIS logs. This number suggests some real probabilities.

· How Popular Will your site be? The popular site will have 1 million or more visits a day. Not so popular? So suppose there are some different situations? Suppose you have more than 1000 user groups? Can you solve scalability problems by adding more hardware devices? Or will the architecture of your program become a bottleneck?

· What is the worst-case scenario? Ask your friend, is this going to happen?

Issues to consider for an intranet:

· Similarly, analyze your existing IIS logs.

· Is this ASP program available to everyone? How many machines are there in the company intranet? Can your system administrator tell you something about the peak traffic in the network?

· Does this program have a specific user object? HR HR department only? How many human resources department employees are in use?

· What's the worst-case scenario?

If you cannot determine the appropriate load in advance, it is your best bet to determine the maximum limit for your program. How many ASP response results can you produce in 1 seconds if clicked by 10 users? What about 100? What about 1000? What about 10,000? Keep track of your benchmarks. When you get your traffic log from actual use showing that you are approaching your limits, you will not only know what your current limits are, but you will have time to prepare for the solution.

Introducing the Test tool was

Although there are a lot of stress test tools to choose from, in this article, I will focus on was (formerly known as Homer), is the current Microsoft's standard Web page stress testing tool. If you are already familiar with Webcat, you will be thrilled to find that was is a convenient way to import existing Webcat scripts. If you've used InetMonitor before, you'll be thrilled to find that was also GUI based (this would be a good add-on for many users of Webcat who use the command line). Another advantage is that it's free, and one of my best friends often says, "if it's free, it's mine." "In addition to its price advantage, this tool provides complete functionality and is constantly upgrading." Microsoft.com often use it, so they will understand the importance of this tool.

But you don't have to listen to me too much, just try it on your own. At the end of the article I will provide a list of some third-party stress testing tools that you can decide on your own. The bottom line is that you need a tool that can put your ASP program under load and test it before it is released.