We currently run a Load Test before every major release, but it usually happens too late to fix any deep architectural issues. I've heard the term "Performance Engineering" used to describe a more continuous approach. What does this look like in practice? Are we just moving our Jmeter scripts into the CI/CD pipeline, or is there more to it?
3 answers
Performance Engineering is about "Observability" and building performance into the design phase. While "Testing" is a reactive check at the end, "Engineering" means you are monitoring CPU, memory, and database latency in every environment—from local dev to production. In practice, this means setting "Performance Budgets" (e.g., this API must return in <200ms) and having the build fail if those are exceeded. You should also use APM tools like New Relic or Datadog to profile code during unit tests. It’s less about running one big "10,000 user test" and more about ensuring that every code change is optimized for efficiency before it ever reaches a scale. Posted by: Patricia Adams Date: 22-06-2023
Are you using "Canary Deployments" to test performance on a small slice of real production traffic before a full rollout?
Load testing in a staging environment is never 100% accurate because the data volume is smaller. Engineering for performance requires "Production-like" data.
Spot on, Nancy. We once passed all our tests in staging but crashed in production because our DB indexes didn't behave the same way with millions of rows.
Joseph, we’ve talked about it, but we’re scared of breaking things for that "Canary" group. How do you mitigate the risk? You use "Feature Flags" and a global load balancer like Cloudflare or AWS ALB to route only 1% of traffic. If the latency spikes or error rates rise for that 1%, the system automatically rolls back. This is the ultimate "Shift-Right" performance strategy—finding real-world bottlenecks without a total site outage.