Performance patterns are blueprints to solve recurring performance problems. The pattern is a general concept for solving a particular situation. Make sure to distinguish a pattern from an algorithm. The pattern is a high-level description of a solution, and the algorithm is a set of actions that can achieve a goal.
What are the elements of a performance pattern?
Intent - summary of the problem and the solution.
Motivation - explanation of the problem and benefits of the solution.
Structure - elements of this pattern.
Example - how you can apply this pattern.
What are the benefits of performance patterns?
Even if you have worked as a performance engineer for many years, you must know you already use such patterns. The main idea behind performance patterns is to eliminate guesswork and introduce an easy-to-understand ruleset for performance engineering.
Performance patterns are a toolkit of tested solutions to common performance problems. If you encounter specific issues, you could look at these patterns and find guidance on how to solve them.
Performance patterns simplify communication and act as a common language. You can say, "Monitoring first," and everyone will understand the suggestion.
We distinguish between creational, structural, and behavioral performance patterns. In this post, I will outline the shift-left behavioral performance pattern.
Behavioral patterns describe how we can make performance a shared responsibility and everyone's daily job. The awareness of these practices is a crucial step towards fast and reliable applications.
Based on my experience, the number one root cause of performance problems is always needing more awareness and management support. It's not about tools but why and how to integrate performance engineering into product development.
Behavioral Performance Pattern / Shift left
Intend: The earlier we detect performance problems, the lower the remediation efforts.
Motivation: Development with performance in mind is crucial for fast and reliable business applications. If our developers consider performance requirements in their development efforts and continuously validate them, they detect flaws earlier and need less effort to solve these problems.
Structure: When you keep your developers busy with coding and do not share instructions on how the new feature should create value or how customers use it, you risk identifying performance flaws too late. At the same time, you should only risk deploying a new feature without proper performance validation in any test or production stage.
Example: Imagine the launch of your new e-commerce application on a Monday morning. Your marketing teams launched their marketing campaigns several weeks ago. One hour before your go-live date, you get a call from your development manager, and he asks for permission to include a final caching-related change, which he still needs to validate under load. Still, the team is confident that everything is all right. Due to the promising message, you accept this final improvement to become part of the go-live.
About 30 minutes post-deployment, the production database response shows massive spikes and angry customers raise problem tickets. The product launch turns into a nightmare for the entire team. During the post-mortem analysis after a long working day, you've realized that the untested last-minute change wiped out all hopes in you as an excellent product manager, and your company lost not only millions but also the trust of their valued customers.
Your lesson learned that day was: Never shortcut Shift-left because Performance is your most important asset, and you realize it only once it's too late.
Behavioral patterns focus on making performance everyone's daily job.
Shift left
Shift right
Observability first
Performance Requirements
And a few more
Where can you get the complete list of performance patterns?
Our team is publishing a book about performance patterns, and you can get it on our webpage soon. So stay tuned, and keep up the great work!
Happy Performance Engineering!
Comentarios