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 likeSecond, 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 code 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.
Another common mistake when load testing is to take applications that will handle millions of unique logins per day, and load test with only one load-generation device. Load tests can be invalid due to the number of requests a load tool is trying to simulate. Many load test suites claim they can emulate hundreds, if not thousands, of simultaneous users. This is not true for all cases -- the sheer volume and bandwidth of the images served from the application make this impractical. In reality, a production system will handle the load from thousands of unique IP addresses. The bottleneck in the load generation is that a single CPU machine with one network card is not able to handle the load -- it is not possible, and you will encounter numerous issues just trying to get this to work.
Another common problem is evenly distributing load across servers. Load testing is performed to try to simulate thousands of users in a mock environment. Having all traffic improperly going to one server will impact your test results. A way to make sure you are simulating the proper traffic patterns is to do IP spoofing. When you have all the IP addresses coming in from a single node, you will see that the session is piling up on one server, and the rest are idle. It is imperative that you check each server in the configuration to ensure they are getting a fair share of load test traffic.
Predicting how a customer is going to use a web site or web application is difficult to do. To be successful you are going to need to find a way to put proper load on the application. A simple way to achieve this is to break down the application by business-use case. Calculate the frequency of the use cases, and script them independently. To have a comprehensive test you can run them in parallel at the rate you would expect the use-cases to be performed. If the application is a replacement of an existing system, then you should know the usage patterns. You can run a load test, and run a web analyzer against your web logs to see if you can find patterns between production results and the load-test environments.
Before you start a load test, you should identify what you want to get out of the test.
What data or outcome will the load test produce?Will you have a go-no-go decision? Are you looking for benchmark data? Do you have an SLA that needs to be met?How are you going to measure the tests? How do you know if the load test was successful? When are you finished with load testing?
Think about the goal of the load test. What are the success criteria and how will we know when the objective is met?
Load testing is a critical component to have a successful application. Before you start load testing your WebLogic application you must ensure that there are measurable goals in place. Once you have the goals it is critical to ensure you load test scripts are a real world scenario. And finally it is important to have deep WebLogic knowledge to help you mitigate issues and make the most use out of your test. In any case, it is not easy to predict the load, and it is even harder to get an accurate representation of the load on the servers. Just do the best you can, and be creative. If you have had experience with servers in the past, you should be able to predict where the server will have issues.
Regardless of the form of load testing you do, formal or not, you need a good understanding of how that application will do in production. The more experienced you are with performance, the better you will be able to predict the behavior of the application. But until you are able to do that, load testing is an absolute must.
