Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic, Java IoT

Weblogic: Article

Approaches to Performance Testing

A best-practices approach to maximize your performance test effort

Performance testing a J2EE application can be a daunting and seemingly confusing task if you don't approach it with the proper plan in place. As with any software development process, you must gather requirements, understand the business needs, and lay out a formal schedule well in advance of the actual testing.

The requirements for the performance testing should be driven by the needs of the business and should be explained with a set of use cases. These can be based on historical data (say, what the load pattern was on the server for a week) or on approximations based on anticipated usage. Once you have an understanding of what you need to test, you need to look at how you want to test your application.

Early on in the development cycle, benchmark tests should be used to determine if any performance regressions are in the application. Benchmark tests are great for gathering repeatable results in a relatively short period of time. The best way to benchmark is to change one and only one parameter between tests. For example, if you want to see if increasing the JVM memory has any impact on the performance of your application, increment the JVM memory in stages (for example, going from 1024 MB to 1224 MB, then to 1524 MB, and finally to 2024 MB) and stop at each stage to gather the results and environment data, record this information, and then move on to the next test. This way you'll have a clear trail to follow when you are analyzing the results of the tests. In the next section I'll discuss what a benchmark test looks like and the best parameters for running these tests.

Later on in the development cycle, after the bugs have been worked out of the application and it has reached a stable point, you can run more complex types of tests to determine how the system will perform under different load patterns. These types of tests are called capacity planning, soak tests, and peak-rest tests, and are designed to test "real-world"-type scenarios by testing the reliability, robustness, and scalability of the application. The descriptions I use below should be taken in the abstract sense because every application's usage pattern will be different. For example, capacity-planning tests are generally used with slow ramp-ups (defined below), but if your application sees quick bursts of traffic during a period of the day, then certainly modify your test to reflect this. Keep in mind, though, that as you change variables in the test (such as the period of ramp-up that I talk about here or the "think-time" of the users) the outcome of the test will vary. It is always a good idea to run a series of baseline tests first to establish a known, controlled environment to compare your changes with later.

Benchmarking
The key to benchmark testing is to have consistently reproducible results. Results that are reproducible allow you to do two things: reduce the number of times you have to rerun those tests, and gain confidence in the product you are testing and the numbers you produce. The performance-testing tool you use can have a great impact on your test results. Assuming two of the metrics you are benchmarking are the response time of the server and the throughput of the server, these are affected by how much load is put onto the server. The amount of load that is put onto the server can come from two different areas: the number of connections (or virtual users) that are hitting the server simultaneously, and the amount of think-time each virtual user has between requests to the server. Obviously, the more users hitting the server, the more load will be generated. Also, the shorter the think-time between requests from each user, the greater the load will be on the server. Combine those two attributes in various ways to come up with different levels of server load. Keep in mind that as you put more load on the server, the throughput will climb (Figure 1), to a point.

At some point, the execute queue starts growing (Figure 2) because all of the threads on the server will be in use. The incoming requests, instead of being processed immediately, will be put into a queue and processed when threads become available.

When the system reaches the point of saturation, the throughput of the server plateaus, and you have reached the maximum for the system given those conditions. However, as server load continues to grow, the response time of the system also grows even as the throughput plateaus.

To have truly reproducible results, the system should be put under a high load with no variability. To accomplish this, the virtual users hitting the server should have 0 seconds of think-time between requests. This is because the server is immediately put under load and will start building an execute queue. If the number of requests (and virtual users) is kept consistent, the results of the benchmarking should be highly accurate and very reproducible.

One question you should raise is, "How do you measure the results?" An average should be taken of the response time and throughput for a given test. The only way to accurately get these numbers though is to load all of the users at once, and then run them for a predetermined amount of time. This is called a "flat" run. The opposite is known as a "ramp-up" run.

The users in a ramp-up run are staggered (adding a few new users every x seconds). The ramp-up run does not allow for accurate and reproducible averages because the load on the system is constantly changing as the users are being added a few at a time. Therefore, the flat run is ideal for getting benchmark numbers (Figure 3).

This is not to discount the value in running ramp-up-style tests. In fact, ramp-up tests are valuable for finding the ballpark in which you think you later want to run flat runs. The beauty of a ramp-up test is that you can see how the measurements change as the load on the system changes. Then you can pick the range you later want to run with flat tests (Figure 4).

The problem with flat runs is that the system will experience "wave" effects. This is visible from all aspects of the system including the CPU utilization.

Additionally, the execute queue experiences this unstable load, and therefore you see the queue growing and shrinking as the load on the system increases and decreases over time.

Finally, the response time of the transactions on the system will also resemble this wave pattern. This occurs when all of the users are doing approximately the same thing at the same time during the test. This will produce very unreliable and inaccurate results, so something must be done to counteract this. There are two ways to gain accurate measurements from these types of results. If the test is allowed to run for a very long duration (sometimes several hours, depending on how long one user iteration takes), eventually a natural sort of randomness will set in and the throughput of the server will "flatten out." Alternatively, measurements can be taken only between two of the breaks in the waves. The drawback of this method is that the duration you are capturing data from is going to be short.

Capacity Planning
For capacity planning-type tests, your goal is to show how far a given application can scale under a specific set of circumstances. Reproducibility is not as important here as it is in benchmark testing because there will often be a randomness factor in the testing. This is introduced to try to simulate a more customer-like or real-world application with a real user load. Often the specific goal is to find out how many concurrent users the system can support below a certain server response time. As an example, the question you may ask is, "How many servers do I need to support 8,000 concurrent users with a response time of 5 seconds or less?" To answer this question, you'll need more information about the system.

To attempt to determine the capacity of the system, several factors must be taken into consideration. Often the total number of users on the system is thrown around (in the hundreds of thousands), but in reality, this number doesn't mean a whole lot. What you really need to know is how many of those users will be hitting the server concurrently. The next thing you need to know is what the think-time or time between requests for each user will be. This is critical because the lower the think-time, the fewer concurrent users the system will be able to support. For example, a system that has users with a 1-second think-time will probably be able to support only a few hundred concurrently. However, a system with a think-time of 30 seconds will be able to support tens of thousands (given that the hardware and application are the same). In the real world, it is often difficult to determine exactly what the think-time of the users is. It is also important to note that in the real world users won't be clicking at exactly that interval every time they send a request.

This is where randomization comes into play. If you know your average user has a think-time of 5 seconds give or take 20 percent, then when you design your load test, ensure that there is 5 seconds +/- 20 percent between every click. Additionally, the notion of "pacing" can be used to introduce more randomness into your load scenario. It works like this: after a virtual user has completed one full set of requests, that user pauses for either a set period of time or a small, randomized period of time (say, 2 seconds +/- 25 percent), and then continues on with the next full set of requests. Combining these two methods of randomization into the test run should provide more of a real world-like scenario.

More Stories By Matt Maccaux

Matt Maccaux is a performance engineer on WebLogic Portal at BEA.

Comments (3) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Deepak Batra 04/26/06 09:08:56 PM EDT

Great article by Matt. It definitely explains the process of WebLogic Performance Tuning & Testing well.

Arcturus (www.arcturustech.com) can help make the process of WebLogic Performance Tuning easy. AutoPilot WL, our flagship product completely automates WebLogic tuning process.

AutoPilot uses a wizard based approach, it takes a load script, generates load and monitors j2ee application & WebLogic's behavior (including transactions, WebLogic threads, ejbs, jms, jdbc, various pools and a lot more..). In the process, AutoPilot analyzes WebLogic & application's cumulative behavior after each run and makes appropriate adjustments to get the optimum performance. AutoPilot also automatically bounces WebLogic server as and when needed in the process. AutoPilot continues this process unless desired goals are achieved or certain user defined thresholds are reached. WebLogic tuning is in a way a misnomer, it is actually aligning WebLogic as per your application and environment's requirements. You can download an evaluation version of AutoPilot at the following url and try it for yourself.

http://support.arcturustech.com/downloadpage.do

You can get more details on WebLogic Performance Tuning Process using AutoPilot at the following URL.

http://support.arcturustech.com/AutoPilot_WL_Help/Tuning_Your_WebLogic_S...

It is recommended by Arcturus to use AutoPilot Advisor before tuning. Advisor analyzes complete application environment for any configuration related issues using its in built knowledge and gives recommendations. It is like attaching your WebLogic environment to a computer that runs a 1000 point inspection on it and either fixes issues or advises how to fix them. Advisor is a great way to find out where there is room for improvement even before you get into Performance Testing & Tuning. It even guides with the relevant BEA CRs that can save an outage situation. We recommend CRs based on their applicability (not blindly).

We also understand no matter how much effort one puts into an application, we are bound to find apllication/weblogic issues that cause WebLogic server to hang. AutoPilot Detector and Blackbox handle those situations and provide you with an instant root cause report. Feel free to drop me an email ([email protected]) if you any questions at all.

Deepak Batra 04/26/06 09:08:21 PM EDT

Great article by Matt. It definitely explains the process of WebLogic Performance Tuning & Testing well.

Arcturus (www.arcturustech.com) can help make the process of WebLogic Performance Tuning easy. AutoPilot WL, our flagship product completely automates WebLogic tuning process.

AutoPilot uses a wizard based approach, it takes a load script, generates load and monitors j2ee application & WebLogic's behavior (including transactions, WebLogic threads, ejbs, jms, jdbc, various pools and a lot more..). In the process, AutoPilot analyzes WebLogic & application's cumulative behavior after each run and makes appropriate adjustments to get the optimum performance. AutoPilot also automatically bounces WebLogic server as and when needed in the process. AutoPilot continues this process unless desired goals are achieved or certain user defined thresholds are reached. WebLogic tuning is in a way a misnomer, it is actually aligning WebLogic as per your application and environment's requirements. You can download an evaluation version of AutoPilot at the following url and try it for yourself.

http://support.arcturustech.com/downloadpage.do

You can get more details on WebLogic Performance Tuning Process using AutoPilot at the following URL.

http://support.arcturustech.com/AutoPilot_WL_Help/Tuning_Your_WebLogic_S...

It is recommended by Arcturus to use AutoPilot Advisor before tuning. Advisor analyzes complete application environment for any configuration related issues using its in built knowledge and gives recommendations. It is like attaching your WebLogic environment to a computer that runs a 1000 point inspection on it and either fixes issues or advises how to fix them. Advisor is a great way to find out where there is room for improvement even before you get into Performance Testing & Tuning. It even guides with the relevant BEA CRs that can save an outage situation. We recommend CRs based on their applicability (not blindly).

We also understand no matter how much effort one puts into an application, we are bound to find apllication/weblogic issues that cause WebLogic server to hang. AutoPilot Detector and Blackbox handle those situations and provide you with an instant root cause report. Feel free to drop me an email ([email protected]) if you any questions at all.

news desk 02/18/06 03:08:31 PM EST

Performance testing a J2EE application can be a daunting and seemingly confusing task if you don't approach it with the proper plan in place. As with any software development process, you must gather requirements, understand the business needs, and lay out a formal schedule well in advance of the actual testing.

IoT & Smart Cities Stories
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...