Your winning performance-engineering strategy
Many companies now understand how, for their customers, performance is paramount. These companies know that the customer tolerance for slow apps is virtually zero. Nowadays, using Agile development methodologies to develop and tune applications for high speed is almost standard. No matter what type of development principal you follow though, you’ll find that fast and reliable applications do require more work in the construction phases. This post will tell you how to create a winning strategy in your performance engineering.
I’ve seen some of the best and the worst performance strategies—some highly successful; others too expensive or complex; and yet others that are mediocre or just a bit hit and miss. Without a balanced and holistic view, even businesses that splash out on all the best tools are still unlikely to achieve their goals. Too much hope is pinned on the idea that simply having the right tools and/or securing the help of a few top engineers will result in reliable and fast-loading IT services. At the end of the day, these resources are still not enough because user experience is below customer expectations.
Experience has taught me that a winning performance-engineering strategy reflects the entire value stream—from requirement analysis through operations. A bit of good guidance on your approach to the task will help you develop and deliver high-performance applications.
Start your performance-engineering activities as early as possible in your SDLC. Create strong performance requirements that reflect usage volumes and response-time targets. Let your developers write unit-test cases robust enough to be re-used for early performance validation.
CICD PT based on unit tests
Make performance validation part of your build pipeline. Otherwise, you’ll probably end up with the headache of running performance tests after the new build has been deployed! Automated performance-baseline testing and reporting is therefore essential, and it prevents your performance-engineering activities from creating a bottleneck. Also, establishing a fully automated performance gate will help speed up your test execution and dramatically increase your test coverage at the same time.
Integration PT based on API level tests
Although CICD-performance testing is great for finding issues related to core functions, it won’t show you any of the errors coming from interactions between components. One of your services might read data provided by another service, for example. When you test both services individually in your CICD PT, you might find the performance is within the agreed boundaries. But even after both services are aligned, you could still experience outliers. You’ll then be faced with the challenge of finding the root cause of these issues. Integration-performance testing means you’ll avoid such negative surprises because it focuses entirely on simulating realistic or scaled-down usage volumes after components or services are integrated.
End-to-End PT based on business-process tests
Customers don’t care how the internal components are performing. So long as their end-to-end use cases are in a good shape they won’t complain about bad performance. Slow services will usually affect the customer experience though, but the customer experience can sometimes still be bad even when the services are fast. That’s why your most important performance tests are the end-to-end scenarios. First you should identify the use cases used most frequently, simulate those tests after a new release has been deployed; and then validate the agreed performance requirements. Following successful validation, release a new version to production.
Do you test your application as it is perceived by your real customers? The geolocation, a low network bandwidth, a user’s operating system and the browser type and version can all have an impact on end-to-end response times. Don’t be surprised if this final validation uncovers glitches in your frontend layer. Following web page design best practices is a good start—you should also validate them regularly during your construction cycles.
Many businesses discover that testing for performance is not sufficient. Those who see it as a cure for all ills soon learn how minor changes such as configuration adjustments can result in massive slowdowns. High-performance levels are not so easy to achieve—all team members need to contribute. You can help your operational teams to adopt the right mindset and integrate transaction tracing and synthetic monitoring, as well as establishing proactive alerting. This shift-right approach enables continuous improvement and provides insights concerning the entire application stack. You’ll also find it very beneficial to introduce information-radiator charts and share relevant key-performance metrics with the entire organization as well.
Performance engineering is meant to be part of the entire value chain. Don’t limit it to software testing.
Feel free to contact me or my team with any questions on how to make performance engineering part of your software-development process.
Happy performance engineering!