Apache Jakarta and Beyond: A Java Programmeramp;#039;s Introduction [Electronic resources] نسخه متنی

7.5. How to Stress Test

To use JMeter effectively a good deal of thought must be given to what should be tested and how the results should be interpreted. There is no short answer, but an excellent guiding principle is that tests should anticipate how the system will be realistically be used. If a system is likely to be used by only a few people at a time, there is no need to hit it with thousands of threads. If there are certain times of day when the load is expected to increase, then the expected peak load should be simulated. A safety margin should always be factored in, which could be anything from 10 percent to 300 percent, based on the kind of fluctuations that are expected. This margin will provide an extra level of comfort that the system will stay up on an unexpectedly busy day.

It is also necessary to consider what users will be doing on a system, as well as how many of them there will be. In the calculator application users will more commonly be submitting numbers to be added than loading the welcome page. Therefore, more threads should be hitting the result page, with a few simultaneously hitting the welcome and input pages.

Tests should be run from multiple machines and, if possible, from machines with different operating systems. Using several machines creates a more realistic test as well as ensuring that each JMeter instance is running at full speed. It is possible that different operating systems will have slight quirks in their network implementations. As remarkable as it may seem, under heavy loads it is possible for these quirks to affect behavior on the server.

Although all the tests in this book have run for a limited number of iterations, a better test would be to let the system run for hours or even days. Sometimes an application will very slowly consume resources, and it may not run out until many thousands of requests have been handled.

Some consideration is also required to determine what constitutes a successful test. The success of all text assertions is a good start, but a page that takes a minute to render is almost as useless to an end user as one that does not render at all. The use of a timing assertion can ensure not only that pages work but that they work well.

For systems that will need to handle very large amounts of traffic it may be necessary to build in some type of graceful performance degradation. Perhaps beyond a certain level of activity the system will need to display pages recommending that users come back later. Tests would then need to be written that ensure that every concurrent request beyond the threshold results in this message. Creating such a test may be difficult, but one way to approach it would be to add two assertions to the sampler, one expecting the normal page and one expecting the delay message. If the threshold is 200 simultaneous requests, then under a load of 300 threads, the former assertion should fail about 33 percent of the time. The exact number of failures should match the number of times the second assertion succeeds.

7.6 Beyond This Book

Although JMeter is written in Java, it executes no code on the server and therefore may be used to test Web application written in Perl or any other language. It may even be used to test how well Web servers serve static content such as fla202 and images.

JMeter is capable of doing much more than testing Web pages. It is also possible to test database queries by specifying JDBC connection info, a SQL command, and the expected results. Often a significant portion of an application's time is spent accessing the database, so performance testing the database components in isolation is often a good step toward improving overall performance.

Although JMeter comes with a rich set of logic controllers, timers, and other components, there is always the possibility that some functionality will be needed that JMeter does not provide. Because JMeter is open source, such functionality could always be added to the base system by modifying or extending the source code. Fortunately this potentially difficult solution is not needed, as JMeter is extensible. Just as the Ant developers foresaw the need to dynamically add new tasks, JMeter allows new elements to be defined and loaded.

The steps to add a feature to JMeter are rather similar to those for adding a new task to Ant. The base system provides a number of interfaces including Timer, SampleListener, ConfigElement, and so on. A new component needs to implement the appropriate interface, most of which are rather simple. Components will also typically implement the JMeterComponentModel interface, which will allow them to be used from the GUI. Finally, all custom components should be placed in a file called "ApacheJMeter.jar" and this jar placed in the classpath. JMeter will automatically find the classes and place them in the appropriate menus.

In practice, creating the GUI is likely to be the most difficult part of this process. Fortunately there are many good templates to start with in the form of the built-in JMeter components.