Improving Application Performance & Customer Data Access

Technology leaders are often tasked with improving the application experience for our customers. This typically means finding a way to get meaningful data into users’ hands sooner in some form or another. Some of that work is technical performance improvements, and sometimes it is a simple change in workflow.

It’s always good practice on the part of the development team to have a strong understanding of how the software is being used and how each of the components is performing. There are a lot of tools to help you such as JMeter, LoadRunner, and Blazemeter (among others), but the goal is to find a tool with which it is easy to get started and a tool that will help a developer begin the process of understanding the performance of specific modules of the application.

Once you have a baseline, a developer can use that information to identify technical debt that needs to be improved. A couple of years ago, I wrote some technical suggestions for addressing low hanging performance and scaling problems. While those suggestions still apply, it’s also good to pay attention to new technology since best practices change rapidly and what worked well two years ago may be superseded by whole new approaches today.

The next developer priority, and perhaps more important than the technical aspects of performance improvements, is understanding how your users are interacting with the software. There may be simple opportunities to change the workflow of the application that can make drastic improvements. A simple example is the scenario in which users are interacting with an application and they are waiting for data or information that has become outdated or less valuable to them over time. In this example, one could either remove this data or push it to a less prominent position that loads as a lower priority. Sometimes a simple re-evaluation of the workflow can identify some simple changes that could make a very large impact. Another common example is to consider whether a user needs a response in a synchronous fashion, and whether changing the UI paradigm to reflect a long running process correctly could avoid chasing expensive optimizations for low ROI.

The above examples are a couple simple points to consider when tasked with improving the performance of an application. Sometimes your individual components are already good enough, and simply asking, “do we need to do x?” may yield much higher gains with very little effort. Although as a software engineer it feels rewarding to streamline various components, one may be saving milliseconds but ignoring seconds or even minutes elsewhere.