Chapter 18. Performance and Stress Testing Your Applications

   

Why Stress Test Your Applications?

It's not uncommon to build a component and discover when you begin testing it that its performance is not what you expected or were hoping it would be. Eventually, this happens to all of us. Truthfully, the fact that this happens is not a bad thing in and of itself. You should not be completely depressed about poor performance the first time you test your components because, during the design and implementation phase, performance should not be your main focus. This is not to say that you should be trying to design or build slow components, but you should be focusing on building your components and applications based on sound object-oriented principles. Taking shortcuts because you are worrying about performance early in the cycle is, more often than not, the wrong approach.

Focusing too much on performance early in the design or development stage is not the best approach mainly because it's hard to determine where the bottlenecks or problems will be without actually testing the component or application. During design and construction, you might believe a certain piece or component of the application will be a problem and find out that a completely different area actually is the problem when the application is built.

One of the biggest mistakes developers make when doing any type of performance or load testing is not doing enough testing before starting to optimize the code. For example, suppose you have two areas in your application that are slow. Unless you do enough testing to know which one is worse , you might work on the area that is causing the least problem. You must do enough testing to know which area to focus on first to get the biggest return on your time investment.

Let's face it; as developers, we are always racing against the clock. Usually, this clock is being set and managed by someone else to get the release to QA or out to a customer. There's hardly ever enough time to do performance or stress testing of the entire application, so you must be wise enough to focus your available testing time in the proper places. The first rule is to do enough up-front testing to identify the problem areas that are causing the biggest reductions in performance. If you have enough time, you obviously want to go through all the problem areas, but if you do find yourself running out of time, at least you can take comfort in the fact that you fixed the big ones.

A very important distinction must be made between performance testing and stress or load testing. Performance testing involves executing the functional requirements for an application and basically timing how long it takes for each result to complete. This action should be executed for all the public interfaces to get a complete picture of how well the application performs . So, for the Auction example, we might test getting the list of auctions that are available, viewing the details of one of the auctions, submitting a bid, and then test the rest of the EJB methods that are exposed to the remote clients . We would record the time that it takes for each action to complete end to end. This sometimes is referred to as a transaction time .

Based on the time that it takes to complete these actions, you would be able to come up with a rough throughput time. Throughput in this sense defines the number of transactions that can occur in a set amount of time. These kinds of numbers also can help network engineers understand how much network bandwidth the application might require.

Stress testing or load testing is a little different from performance testing but is somewhat related . With performance testing, the number of users used when testing performance typically is one. With load testing, the tests simulate a larger number of users and evaluate how the application reacts as the number of users grows. Things such as transaction time, throughput, and memory used can be recorded to get a picture of how the system will handle itself under a heavier load.

Note

Although there can be some subtle differences between stress testing and load testing, we are using the terms interchangeably throughout this chapter.


You must do both types of testing in your EJB applications. Both tests can give you important information about how well the application is designed and constructed and can point to parts of the application that might become a bottleneck, under normal loads or especially as the number of users increases .



Special Edition Using Enterprise JavaBeans 2.0
Special Edition Using Enterprise JavaBeans 2.0
ISBN: 0789725673
EAN: 2147483647
Year: 2000
Pages: 223

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net