Improving the performance of financial applications often leads to a call for additional or larger servers. However, performance is always a sum of functional elements, user perception and hardware.
5 recommendations from the practice of performance tuning:
Base the optimal performance on the usability of the system and create a benchmark for the usability. Consider questions like ‘What should the application do?’ and ‘Can anyone use it well?’. When you move from 5 seconds response time to 3, you improve the performance, but not the effectiveness of the application. With a benchmark you always have an objective standard to refer to, which will help you in your communication with the end users.
Firstly, analyse where most time is lost during a process. This allows you to judge the performance when only one user is active. Often, this will give you an insight in the functional elements which can be improved. This not only increases performance, but also shows you which technical issues need to be solved.
Optimum performance is all about smart investing. This requires an integrated approach, including technology, infrastructure and functional design. Often, it is not sensible to install a larger server or to ask a generic database specialist to have a look at the database. To improve performance you’ll need to integrate the various components and functions of the application.
Before going live, try to get a picture of application behavior during heavy usage. Load simulation software will show the capacity of the platform to have several users carrying out the same scenario. What is the effect on performance and hardware? What are the bottlenecks? And what do we find acceptable? Suppose there are 50 concurrent users, which percentage loss in response time compared to the benchmark is acceptable?
Note the consistency of different processes. Some processes impose a heavy burden on the system and hence hinder the other users in the road. If one user performs a batch process, such as a consolidation or an import, the other users experience a delay in their reports. If you can make these processes faster in the application, the application is immediately more scalable. If you drive cars instead of trucks, the capacity of the road goes up dramatically.
Make performance measurements a permanent part of the support cycle and application life cycle management. Before major changes, do not only rate the functional consequences, but also the effects on performance. Use the benchmark from step 1 to see what your performance gain will be.
Text: Bert Dotinga