Historically, cartographers would place dragons or other imaginary great beasts to fill in areas of a map that were unexplored. It was a simple placeholder for all the unknowns. Unfortunately, shipwrights did not have the luxury of ambiguity and had to imagine what could happen, in order to build ships that could withstand all.
Similarly, as you are designing an analytics application, you have to understand potential performance problems and prepare for them. Building a highly performant application means navigating the perils of the high seas in a largely distributed IT infrastructure environment. It requires having full visibility into everything that affects your end-user experience, including web code, infrastructure, database connectivity, and external dependencies.
Let’s take a different lens to determine what performant means and how to decide what to measure to get there. We need to explore why it’s important to create a baseline for user experience, monitor actual performance against the baseline, and tie performance directly to your business goals.
The first step is determining whether your analytics application is “available” to its end users. Availability may mean different things to various stakeholders. From a DevOps perspective, a successful ping to the server means the application is up and running. That particular metric, however, may be meaningless to a CEO who considers availability to mean accessing their dashboard without a problem.
The most successful applications implement performance plans with their end users in mind. End users have high expectations of interactions with applications and the seamlessness of their experience. They expect reliable application access and predictable performance. A research study on user experience revealed that one second is the longest wait time for end-users to stay within their flow. After ten seconds a user’s attention will be lost unless there is feedback to keep them engaged. A focus on the end-user experience allows you to identify meaningful indicators of application availability. Start by defining the minimum user experience and ensuring their expectations are met, and then use data from that point to improve your application.
The second step to creating a performant application is to figure out what to measure. Each application has several layers (application, components, services, and infrastructure), and each stack has its own metrics and monitoring methodologies. A lot of “noise” is generated in the monitoring data, and it can seem daunting to know what to measure and monitor. Figuring out what is important to your end-users gives you a starting point and a goal. Keep in mind that the purpose of performance monitoring is to detect issues in a system and minimize their impact on the end-user.
The final step will be to keep an eye on our overall process by defining Key Performance Indicators. Two important KPIs to consider are:
A. Mean Time to Detect (MTTD): The average amount of time it takes to discover an issue.
B. Mean Time to Resolve (MTTR): The average amount of time it takes to resolve an issue.
As application developers, we are required to maintain visibility into all of the areas that influence the end user’s experience. This can mean navigating competing priorities, budgetary issues, and stakeholder requirements. However, maintaining the primacy of the end user’s experience can be our guide through murky waters. There will always be unexpected performance problems, our proverbial dragons, but we can plan for them and navigate our way through.
Every data-driven project calls for a review of your data architecture. Download the white paper to see the 7 most common approaches to building a high-performance data architecture for embedded analytics.