Part 1: Common Mistakes in Performance Testing - Running Tests from Your Local Machine

#loadtesting #performance #testing

Hey, I'm Oleh — a Performance QA Engineer who has been breaking systems professionally for a while now. In a good way, of course.

I also teach performance testing — you can check out my hands-on course below:

🎯 Performance Testing: From Basics to Hands-On

We're starting a series: Common Mistakes in Performance Testing that I usually see. Each part covers one mistake in depth. Today — the one that surprises people the most when they first hear it.

The Problem

You built a great script. Results look terrible. Before blaming the app — where did you run the test from?

Before you start blaming the app — where exactly did you run that test from?

One of the most common mistakes I see is engineers running load tests from their local machine while the application is hosted somewhere completely different. Say, you're sitting in Europe, your app is deployed in the US, and you're wondering why response times look so bad.

Here's the thing — your test is not just measuring how the app performs. It's measuring the network latency between your laptop and the server.

And that latency can easily add 200–400ms per request. I've even seen cases where it turned 200ms into 5–7 seconds. Multiply that by hundreds of virtual users sending thousands of requests — and your results are just noise.

Real users of your app are not sitting in your living room. They're distributed. And your load generator should reflect that.

What To Do Instead

Run your tests from a machine that is close to where your application is hosted — or better, from a cloud-based load generator in the same region. Most modern tools like Grafana Cloud, BlazeMeter or Azure Load Testing let you choose the region. Use it.

If you're testing a global app — spin up agents in multiple regions and see how latency affects different user groups. That's a much more realistic picture.

Quick checklist before your next test run