6 Common Performance Testing Mistakes

Being a performance testing consultant for the last 15 years, you could say that it's second character 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 maybe the technology being used, the same types of performance testing faults get made over, and over, and over.

This particular is fundamentally unsurprising, as human nature is the same regardless of the company, and every job and business environment has deadlines. Sometimes those deadlines mean testing simply has to get done, rendering it easy to cut sides to get the results "over the queue. " Unfortunately, however, those short-cuts can lead to costly performance testing mistakes and oversights.

With a lttle bit of self-awareness, however, not to talk about helpful accompanying tools like Flood, you can often mitigate these mistakes quite easily.

1. Inadequate Customer Think Time in Intrigue

Hitting your application with hundreds or thousands of requests per second with no think time should be used in rare cases where you need to simulate this type of behavior (perhaps a Denial of Support attack? ). I'd like to feel that 99% of individuals are not testing just for this scenario all the time, and are just attempting to verify that their site can handle a particular target load, so your user think time is very important.

We have seen many people run tests with no think time, with thousands of users, using 1 load injections node, and then proceed to ask: "Why are my response times really slow? When I personally look at the site using my browser, it appears to be responding all right? "

The cause of this is almost always due to the sheer amount of requests that the load injection node is tasked with, which eventually runs into maxing out there machine resources and activating local exceptions pretty quickly.

2. Using an Inaccurate Work load Model

A workload model is essentially the in depth plan that you should be writing your scripts against. This workload model should outline your business processes, the steps involved, number of users, quantity of transactions per consumer, and calculated pacing for each and every user.

As possible probably see, having an exact workload model is critical to the overall success of your testing. Often this is simpler said than done - there have been many projects where business requirements simply don't exist because they just weren't considered beyond, "the system should be fast".

It's almost become area of the job explanation of a performance tester to assist in nailing down these requirements . usually sitting with the analyst or business representative involved to flesh these out in order to have something accurate to test against.

It is also common that non-functional requirements tend to have lofty and ambitious target transaction and response time figures, often proposed by an overly enthusiastic business team or representative. This is typically related to the buzz created for a new application and target functionality that the business is eager to release.

3. Setting Up Inadequate Infrastructure Monitoring

Load technology isn't the only important part of the performance testing scenario. The execution results gained from your scenario such as throughput, transaction reaction times, and error information isn't overly helpful unless you can see how your target infrastructure is actually dealing with the situation.

It's a common problem - I have heard many testers ask why their response times are taking minutes rather than seconds. Typically the problem can lie either in the load technology or the target program infrastructure.

4. Use of Hardcoded Data in Every Request

Another common mistake is when customers test their websites with the same exact request frequently. The goal of weight testing is to be as realistic as possible - so the use of the identical data in your HTTP request for each one of your users is not how this scenario would play out in reality. Often smarter applications and existing database technology will recognize these exact same asks for and begin automatically caching them, that will have the result of the overall system appearing faster than it really is. This brings about an incorrect performance test.

Overloading Fill Generators

The last of performance testing mistakes is the overloading of load generator due to 1 or more of the following:

• Too many concurrent users on a single load injection node.
• The target site is very image-heavy or CSS-heavy, which impacts the amount of concurrent users you can fit on a load injection node.
• Load injection client hardware limitations.