Many companies run load tests to determine the performance of their WebLogic Applications. The challenge they face is that they run load tests but do not get the results they are looking for or the load test FAILS every time. The net effect is they do not complete the load tests or have unsatisfactory test results. There is a go-no-go decision for the application, based on that decision the application either gets put on the back shelf or goes to production with serious performance issues. I worked with a customer who had been running and failing load tests for 8 months straight. After assessing the situation there were two main reasons why this application failed load test. The first reason was they did not create the load generation scripts correctly. The scripts they wrote assumed a new user each time. In production that would not be the case. In production a user would log in and stay logged in. The second issue was with an improperly written line of code. Fixing the scripts and changing one line of code in the application allowed the customer to pass their load test and promote the application to production. The time to identify and fix the issues was only a matter of days.
To successfully launch a web application it is important emulate production data and be able to quickly mitigate performance issues. There are two key initiatives that help make your load tests successful.
First, ensure your load generation scripts are representative of what production traffic will look like
Second, identify and fix issues keeping the load test from being a success.
A load test effort can be simple or complex; a simple test can be accomplished by running a script from a desktop against a WebLogic application. You record the results and determine a pass fail for the effort. This is the simple low volume test that can help application owners feel comfortable before proceeding with the launch of their application or CFR changes to the application. Complex high volume applications require a larger much more in-depth process. For starters a high volume application must be written and architected for the higher load. For applications like these companies have a comprehensive test plan using a commercially available load generation tool. In an enterprise the cost of a load test may run into millions of dollars.
Over the numerous load-tests I have been a part of, I not seen at TEST that one-hundred-percent directly emulated what production load would look like. The best that you can do is to approximate the expected load and hope it is a close to what production will look like.
The load-generation tools range from a simple request from a browser to complex load-testing tools with multiple agents and controllers that drive load to your applications. The Grinder is simple tool you can use to drive load to your environment. This is a free tool, compared to Segue, Load Runner and a variety of other tools that are not free but used frequently in the enterprise environments. In some situations in an enterprise-application testing, the Grinder tool can be useful when you need to quickly test a component and do not have the resources or time to go through a formal load test plan.
Developers can write their own programs to hit the servers and simulate load on the system. They will write a tool that calls their application multiple times, and it will time the round trip for this request. It is very simple but effective test. The developers understand what their code is doing and can should be included or encourage to provide support when load testing your applications.
