The performance of world-class athletes as they train for the Olympic Games and engineering the performance of your applications in preparation for production releases share some interesting traits. In this blog, I want to share some basic guiding principles that will help make your applications finish strong. Efficiency, Not Just Speed Not every Olympic sport is a speed race. There are plenty of other areas where winning is about strength or agility. All events arent equal in terms of physical demands, nor do all events focus on the same kind of capability. Efficiency is the common thread. Whether you are skiing down a slope or lifting a heavy weight, generally the more efficiently the tasks are carried out, the better the score. When it comes to applications, the same is true. Many times, performance engineering as an activity is all about measuring how fast something is or how fast it can be tuned to be. However, speed for the sake of speed can lead to other issues. I have heard many clients state that their main goal was to make performance testing automated and repeatable in a Continuous Integration (CI) pipeline. Building out this automation so it is a faster way to test isnt valuable in and of itself. It is about getting performance feedback as soon as possible, and in an automated fashion. What if this fast, automated testing CI pipeline doesnt find performance problems, but your organization still wrestles with performance issues in production? It may be that what you automated to run so fast isnt the right thing. What happens when making things faster is actually a failure? What if the timing is faster because important verifications in the code were not included in the latest build by accident? The timing improves, but the verification check that is missing means critical data could be lost. In this case, faster is not better. Instead of focusing on speed, focus on efficiency. This means reducing the amount of toil and repetitive tasks that computers are better at. This doesnt replace the need for manual review at key intersections within the software development life cycle. Someone who understands the code still needs to verify the results. It also means utilizing every resource to its full potential, while containing infrastructure operational costs and keeping the cloud bills low. Look at all aspects of the system under test and determine how to most efficiently use each component. This will get you started towards creating and maintaining Olympian applications. Observe and Monitor Have you noticed all of the things athletes have to monitor? Speed, heart rate, body fat ratio, etc? Why do they do this? To determine their health. What about all the statistics that come out of the Olympic games? Every kind of metric possible about a sport is tracked and available online within minutes. Why? To monitor and determine the performance of the athletes. This reveals how it impacts the sport overall. Applications need to be monitored to determine health and performance. End user experience can be timed with synthetic processes that run every few minutes and report back page times. Real User Monitoring can time actual live sessions across a wide range of users to determine if there are performance issues with specific user types or geographic regions. Infrastructure monitoring can tell if any system resources are running low, being throttled, or throwing errors. Logs can be parsed to see the response times of individual requests. Code can be profiled to see how heavy each function is, and databases can be profiled to see how expensive each request for data is. The network can be monitored to determine if there is enough bandwidth to service the number of requests. Monitoring of modem applications built on microservices and containers need additional telemetry from hop to hop. The path from the server to the user might be different each time a request is made, and the container that was used an hour ago may not even exist because the application is elastic. In all of these cases, what gets measured is important to finding root causes of performance issues, and the health of the overall system. Just producing load on a system with a performance testing tool without monitoring is not a valuable exercise. You might determine which user timings are high, but you wont know why. The value in any performance testing tool is the ability to provide meaningful results to the business, and these come from graphs that include key metrics. Those metrics are from the monitoring being utilized. You can over-monitor to the point of affecting the performance of the system itself, so it is important to find the right balance. Even then, there is a lot of data and it may require special expertise to make sense of it all. Some products actually use AI and machine learning to help with this, but human expertise is still a requirement. What are you looking at to determine the health and performance of your applications? Rinse