Perftiquette #1

by Perfluencer

Well designed performance tests can point to any environment at any time. The downside is, they will point to any environment, at any time. Even when not expected.
It takes a single parameter change to run your production-scale stress test on a tiny environment you’ve just used to validate your scripts on. Sometimes it can also be a bad load balancer/environment configuration. Other time, the load generators can become unresponsive and won’t stop sending the load long after your test has “completed”.
Performance tests are heavy by design. They’ve even named a load testing tool after .70 multiple barrel firearm (although arguably they may have named it like that because it took at least 4 men to use a Gatling gun). This description should be enough for you to know what happens to an environment you would point your load test to. there’s a lot of mess to be cleaned up, and most importantly, you’re interrupting someone else’s work.


Accidents like that happen; in my early days of performance testing I once ran a load test against a test environment but one of the email notifications addresses was still pointing to production. Fortunately it was not the customer’s email, but the customer service. They still weren’t happy about receiving over 100K emails.


The good practice I follow is to make my tests traceable back to the executing tester, using logs/monitoring tools.
You can enter your name/identifier in request headers, redundant parameters and message payload so the environment owners know who to reach out to in case of a human error.

hashtag#performanceengineering hashtag#pefrormancetesting hashtag#perftiquette hashtag#humour hashtag#stresstest