Performance testing without a target is like running a race with no finish line.
Did you win or did you stop early?
I previously shared my thoughts on benchmark and endurance tests, but before ever running a test, a target must be defined.
🎯 Why Set Targets?
Without a target, how do you know what good looks like?
I've often come across teams that have incorporated performance testing into their releases (which is excellent). But they had no targets defined.
No production baseline.
No service-level objectives from the business.
_How did they know whether the system was meeting expectations?_They didn't.
In some cases, after targets were defined, the system was performing as needed.
In others, it clearly wasn't, and the team had no idea until targets were defined and compared with production.
🏆 Defining Targets
It's easier to define targets for existing systems (and modernization projects) than for a brand-new system.
Existing platforms have production numbers you can reference, user expectations, and service-level objectives that can be translated into performance targets.
New systems rarely have much to baseline from.
For a brand-new system, I like to work with the product/business team and understand their goals.
- 📈 What is the expected growth? Slow and steady, or fast and unpredictable?
- 🚨 What is the criticality of the platform? If it fails to respond, is it a problem or an inconvenience?
- 🌟 What unique constraints or features of the platform might influence performance requirements?
Once defined, targets should not be treated as static.
As traffic starts, you can adjust targets accordingly. Maybe it's higher, perhaps it's lower.
🪫 Leave Some Buffer
Once a target is agreed upon, I like to add a bit of buffer.
If the requirement is 100ms, I’ll target closer to 75ms, or lower, depending on the system and its purpose.
_Why?_Adding capacity or tuning the system takes time.
Things change, sometimes in unexpected ways.
Sometimes unexpected changes can be handled by automatic/manual scaling, but not always.
It's important to give yourself a bit of buffer to respond to those changes.
🧠 Final Thoughts
I've talked a lot about setting targets and their importance. But one of the most important aspects of having targets is monitoring and measuring production.
Having visibility in production helps validate that your targets are realistic.
Maybe they are too high, and you have wasted infrastructure reserved.
Perhaps they are too low, and you won't be able to survive the next traffic spike.
Traffic changes over time, and application performance naturally drifts as new capabilities are added.
Clear visibility into traffic and latency patterns is essential for anyone operating mission-critical, large-scale systems.
But also a foundational practice for most platforms.
Do you have performance targets for your platform? Is it grounded in production measurements? Should you?
Top comments (0)