We are extremely focused towards launching new features and gradually fail to address user experience requirements. It’s a fact that two of three performance issues are related to poor application design. Read this post and learn how to turn your ship around and make user experience and performance a fundamental part of your development chain.
Performance by design
New development procedures such as agile support fast time to market. The flipside is that this euphoric hurry for the next big thing gives you not enough time for performance and reliability considerations. If you are a high-risk taker, this might be acceptable. From a financial perspective, such a performance last approach can quickly develop into a nightmare.
User expect 2 seconds response times or less, and they won’t convert to a buying customer if your application is too slow. BBC, for instance, has found out that 1 sec performance increase will reduce their return on sales by 10 percent.
Takeaway: Make performance engineering a fundamental part in your entire development process. Document your nonfunctional requirements and consider those in your application design decisions.
Shift left
The point in time when your teams identify performance hotspots is critical. Load and performance specific failures such as memory leaks, slow service requests or deadlocks are difficult to identify, and the same is true when it comes to implementing a fix for those nasty mistakes. A memory leak investigation often requires several load test executions while performance specialists collect and analyze heap dumps. Once your engineers have identified the problem spot, they will give you an advice how to fix such issues. In many cases, a massive re-design will be required to overcome performance bottlenecks.
Takeaway: Start performance validation once the first components have been developed, and repeat those performance checks regularly. There is no need to simulate production volumes. Check communication patterns, set thresholds, and conduct a detailed analysis if you experience deviations.
Performance validation
No matter what development process your projects follow, at some point in time end-to-end or user acceptance tests will be executed. Such tests are check ing functionality of the new application from a functional perspective. There is no chance to identify reliability or performance issues when your teams manually execute a few functional tests. You have nonfunctional requirements in place which outlines what load volume will hit the new system once being deployed at productio , but you have no idea how response times, error rate and stability of the new application will be on a production like an environment under realistic and peak load conditions.
Once the entire application is working end-to-end, you should implement and execute a real production like load and performance test. The simulation type can be a make or break criteria. Modern web applications communicate asynchronously with your backend, and a low-level simulation type such as protocol-based won’t capture such requests. Simulation of real browser-based load tests is the way to go for many applications. In addition to realistic user simulation, the data sets must be meaningful and close to production. You will execute several runs of current average, peak, and future growth volume tests. Carefully review your end-to-end and backend performance metrics once your test run has completed. If response times or error rates are above expectations, you will start your root-cause analysis and support technical teams to fix this issue.
Takeaway: Shift left alone will not prevent you from becoming a victim of severe performance bottlenecks. Simulation of realistic production user and transaction volumes on close to production environments is your final and most crucial performance validation gate.
Shift right
Proactivity is an excellent attitude, but things will change over time, and you need to figure out how much impact will specific user, content or data volumes have on your production system. You will experience that a performance gate is no 100 percent guarantee for zero bottlenecks at your live environment and therefore successful IT leaders switched to a shift right approach because this is giving them excellent insights to how user experience and application performance are at production. Research has shown that 1 of 10 customers who experience slowdowns will escalate such problems to your support teams. 9 out of those 10 will keep your brand as not performing well in their mind and 5 of them will never use your services again. Every change brings the risk that you will experience such issues as described above. A shift to the right will help you to establish a culture of performance and continuous optimization. Share this monitoring data with developers, architects, and testing teams. It can be an eye-opener once those teams see how their new application performs at production.
Takeaway: A shift right will help you to understand the undefined, unknown and unexpected. Real customer’s requests for production are the final performance validation of your new system. You won’t miss it to see how your new system performs at this stage. 24 x 7 performance monitoring is the quintessence of such a right shift approach. Your benefits are quick hotspot investigation, shorter times to repair and no need to reproduce issues.
Where to go from there
Based on my experience, pragmatic performance considerations will reduce your costs, help you to manage risks and improves the reliability of your business applications.
Are you ready to improve the reliability of your business applications while helping to ensure better performance at a lower cost? No problem, contact me today!