Instead of being preoccupied with the mechanics of performance for their services, the most successful IT leaders are free to focus on more important things instead. That’s because their teams have identified the best ways to achieve the top levels of performance. And they know how to maintain it. This post shows you how to transform your performance engineering into a winning strategy.
How effective the strategy is
Return on performance is a good indicator of how effective your performance-engineering, testing and monitoring activities actually are. In one of my earlier posts, I mentioned the criteria you should consider when selecting the tools and activities for optimizing the speed of your applications. You can easily waste money by choosing the wrong tools or using inappropriate tactics. A well-balanced performance-engineering strategy that reflects both pre- and post-production optimization activities will help you to minimize the cost. It’s all about experience, working proactively, and providing transparency for current performance indicators.
How often I use it
APM and UEM Real-user performance monitoring and transaction tracing are among the most powerful tactics in the development, analysis, and operation of high-speed applications. This tool provides a neat overview on KPIs, it collects all the important metrics, and points to the root cause of hotspots at the same time. I wouldn’t be without it for performance testing or performance monitoring.
Synthetic monitoring Don’t leave it to your customers to check and report the health status of your key services. A robot that mimics user actions, and then reports the issues identified, is much more efficient. Implement synthetic monitoring early on—during dev or testing stages—and for up-time monitoring on pre-production. Synthetic monitoring also provides a good smoke test for the functionality after a change to your application is deployed.
CICD-performance testing Shifting performance testing to the left helps identify hotspots earlier in the SDLC, and provides a continuous performance baseline. Developers are no longer locked out and can identify slowdowns by themselves. The earlier they fix such issues, the more they will minimize the corresponding defect costs. Make CICD-performance testing part of your build process, and establish an automated performance gate.
E2E-performance testing Let’s assume you have a perfect CICD performance testing in place. So why should you consider E2E-testing activities? Early performance testing is usually based on a scaled-down load pattern and on API-level testing. The E2E performance has not been validated before, and you shouldn’t release deployment to production prior to testing the new release under real production conditions. E2E testing acts as the final performance gatekeeper.
API-performance testing Robust load simulation scripts are not easy to implement. Based on my experience, API-level load injection is a reliable way to get rid of troubles with your testing scripts. Web services don’t change often, but when there is a change, an adjustment of your script is simple. Conduct API-level integration tests to validate the performance after the code of one sprint is merged and before the next sprint is started.
Stress testing Marketing campaigns, weather conditions or seasonal events can introduce a high user and data volume to your IT services. Your operational teams need to be aware of capacity limitations. Stress testing is a useful gauge of the number of concurrent users an application can handle. They can use this information for their alerting or capacity-planning activities.
Don’t wait—start implementing these tactics now! If you have any questions concerning how to make performance engineering part of your value stream, please contact me or my team.
Happy performance engineering!
Comments