Earlier this year I wrote a post about Synthetic Testing and Real User Monitoring, and explained why these are complementary, not competing, approaches. Similarly, Performance Testing — aka synthetic testing – and APM — Application Performance Management and monitoring solutions are similar in that they are often regarded as two competing solutions, as if one were an alternative to the other. They are actually perfect complementary tools to achieve optimal performance for your application. Whether you develop web applications, SaaS products or mobile apps, you’ll find both approaches to be absolutely necessary in your software operations. Here, I explain why. (I’ll use ‘monitoring solutions’ as a synonym for APM solutions.)
But let’s talk about performance for a moment. Performance can refer to end-user performance or backend performance.
End-user performance is a measurement of the user experience as relates to speed, responsiveness and scalability. Page load time is a one of the typical metrics for the user experience.
Backend performance, as the name suggests, refers to the measures related to the backend resources used by the application. This is something end users may not be aware of, but which is important to the way the app performs.
Let’s look at APM or monitoring solutions first. These tools are normally used to collect data from a live environment. Monitoring solutions help gather important information on the application backend metrics, server behaviors, slow components and transactions. Several application monitoring solutions track database and browser performance as well.
There are many kinds of monitoring solutions that operate at different levels of the stack, with different timing granularity, with the opportunity to define custom metrics. You have server monitoring, infrastructure monitoring user monitoring, high-frequency metrics, and others. What is clear with monitoring solutions is that one is not enough. You probably need a portfolio of tools to have a clear understanding of what is happening with your application. Most tools have alerts systems that provide real-time information on page load and are designed to notify you in real time of events just happened so you are immediately informed about deteriorating performance.
However, monitoring is not enough.
It doesn’t matter how comprehensive your monitoring architecture is, it doesn’t provide the full picture. First of all, live traffic is noisy. You have no control over what your users are doing and how many users you have at any given point. If you have a performance issue, that makes it really hard to troubleshoot. Was that expected behavior? Did they just hit a corner case previously unanticipated? Is a combination of the live workloads that crashed the system? So even though the technology is designed to enable real-time troubleshooting, the reality is that since it’s not a controlled environment, you might not be able to root cause performance issues in a timely manner.
Second and most important, the information produced by monitoring is delivered after the fact. Monitoring is like calling AAA after an accident. It’s a great service to have, but it’s much better to prevent the accident in the first place.
This explains why you need to add performance testing to the mix. While monitoring can inform you about performance after the fact, performance testing can help you prevent bad things from happening.
While monitoring is usually done on your live/production environment, performance testing usually utilizes synthetic traffic on a pre-production/staging environment. Having a pre-production environment as close as possible to your production environment will help you derive the most meaningful results.
In performance testing, users are simulated but the traffic is absolutely real. You can apply different types of loads to discover the breaking point of your application before it goes live. You can use performance testing to test with traffic that is higher than anything your actual application has seen — yet — so that you can prepare for peak of traffic. Performance testing can also help you identify performance degradations that might have resulted from code changes, infrastructure changes or third party changes. It basically answers the question: ‘Can you trust this build to deliver the same user experience your users are counting on?’
And, if you are using Docker or containers-based architecture, you could also test performance improvements, under different configurations and platforms easily.
With performance testing, you can also measure end-to-end performance — a good indication of user experience — which gives visibility into the entire application delivery chain, enabling greater transparency and targeted troubleshooting.
At Nouvola, we often say that you wouldn’t build a bridge and then send hundreds of thousands of cars over it without first doing structural tests for structural problems. But you also wouldn’t open a bridge to traffic without continually monitoring how it is holding up under all the traffic. You need to do both, whether you’re talking about bridges or apps. The difference is, while a bridge is static and needs to be tested only once or at periodic intervals, software today is highly dynamic and needs to be tested on a daily basis as part of your regular flow.
Used together, performance testing and monitoring make a great team, so to speak. Use both to make sure you deploy a reliable product.