6 Common Software Performance Testing Mistakes

As a performance testing consultant for the last 15 years, you could say that it’s second nature for me to look for performance patterns. One of the patterns I have observed over my career is that, regardless of the project size, company, or the technology being used, the same types of performance testing mistakes get made over, and over, and over.

This is fundamentally unsurprising, because human nature may be the exact same whatever the company, and also every undertaking and business environment continues to deadlines. Sometimes those deadlines I am testing only have to be carried out, making it simple to cut corners to get the outcomes “within the lineup". Unfortunately yet, these short-cuts may cause costly effectiveness testing errors and oversights.

Having a bit of self-awareness but and of course valuable accompanying resources like Flood, you may often mitigate those errors quite easily.

1. Inadequate user think time in scripts

Hitting your app using hundreds or even thousands of requests per minute without any think time should just be used in rare cases in which you need to simulate this type of behavior (maybe a Denial of Service attack?). I'd like to think that 99% of people are not testing to this situation all of the time, and therefore are merely hoping to verify their site will deal with a particular goal load -- consequently your user consideration is essential.

2. Using an inaccurate workload model

A workload version is basically the comprehensive plan that you should really be writing your own scripts versus. This work-load model should summarize your small business processes, the measures included, the number of people, amount of trades a consumer, and also calculated pacing for each user.

Because you are likely able to see, having a true workload model is equally critical to the overall success of one's own testing. Frequently it is simpler said than done -- there has been lots of projects where firm requirements simply don't exist due to the fact they just ended believed outside," the device needs to really be rapid".

It's become a portion of this job description of a Performance Tester to help out with nailing down these requirements -- regularly seated together with the adviser or company representative required to flesh out these in sequence to really have something true to check.

3. Setting up inadequate infrastructure monitoring

Load creation is not the sole important part of software performance testing scenario. The implementation results gained in the scenario like throughput, trade response times, and also malfunction information isn't too helpful if you don't may determine how you concentrate on infrastructure is really coping with this circumstance.

This is a typical problem -- I have heard many reviewers consult why their response times are taking minutes instead of minutes. The issue can lie in the loading generation or the target program infrastructure.

So just how can you fix this issue? The ideal solution would be always to have habit tracking dashboards (that can be available upon request from several load testing platforms, such as Flood IO) to get most of your on-demand loading shot infrastructure. This gives you the opportunity to see system resource utilization while running your evaluations, making sure that no bottlenecks are present on the load generation side.

4. Usage of hardcoded data in every request

Another typical pitfall is when consumers examine their sites with the same precise petition.

The goal of loading testing is always to be as realistic as possible -- thus the using the exact same data on your HTTP request for every one of your consumers is how this situation would play out from fact. Usually brighter applications and active database tech will probably recognize these specific same orders and start automatically caching them -- which will have the effect of the overall system appearing quicker than it happens to be. This results in an invalid operation evaluation.

Let's consider the simple act of enrolling a new user for a typical online shopping site. Most (if not all of these websites) will not allow precisely the exact same person to be registered more than once with no distinctive information being given.

5. Ignoring system or script errors even though response times and throughput may look fine

When running a load test -- you can find several things to keep tabs on to ensure you are running a legitimate evaluation. It is very simple to shine a few details that could possess a tremendous effect on your test's validity. Simply take the following example that can be seen very often:

A load evaluation functions with a target quantity of people and also an individual finds response times and error levels to maintain decent ranges. Yet anticipated throughput is much lower than expected. How can this be if Flood is reporting almost no transaction relevant glitches?

6. Overloading load generators

The final of our 6 frequent Effectiveness testing mistakes is your overloading of loading generators because of a single or more of these following:

A. way too numerous concurrent users onto a single load shot node

b. The target site is very hefty image or CSS heavy that affects the number of concurrent users You're Able to fit onto a loading injection node

C. Load shot node hardware limits

In Flood, we have base-lined our load production nodes into a spot where we now understand we are able to successfully support up to 1000 concurrent users per burden node for Jmeter and also Gatling evaluations. This is an overall rule of thumb and your mileage may vary depending on your mark site. A site heavy in CSS and tons of graphics will probably cause a much larger footprint in resource usage than the usual exact the straightforward text merely web page or API calls.