As the FOD Rental Platform attracts more customers and suppliers it sees more users logging in each day to perform their rental management tasks. Additionally as time passes the platform’s data stores grow in size, accommodating more of the current and historical data it uses. Inevitably, the busier and larger any computer system gets, the slower it will perform if left unchanged. It’s part of the FOD Development Team’s remit to address this, tuning the platform to keep it running optimally.
Rental Platform usage growth since launch
The Right Approach
There is a famous maxim in software development that paraphrased states that ‘most early optimisation is counter-productive’, instead it is better to measure performance and then optimise where needed. While scalability is a core requirement of all of our system developments, experience has indeed shown us that it is hard to predict all potential bottlenecks in advance. To this end, we have put in place a number of monitoring and diagnostic tools to help us to identify and investigate performance problems that arise. Chief amongst these is the software/service ‘New Relic’ which monitors web application performance on the FOD web server, on user’s devices and in their browsers.
A typical week on the web server, across the Internet, via browser to user
We have further configured New Relic to be able to track performance across the system as a whole, for each rental operator and for suppliers. This tool also traces individual pages on the system and allows us to tie this information with our own logging, tracking every page request each user makes. This then allows us to investigate in detail individual reports of slower performance in addition to monitoring system-wide behaviour.
The Best Solutions
Like other FOD systems, the Rental Platform sits upon the FOD Web Framework that (amongst many other benefits) allows some optimisations to be made in once place but improve the system as a whole. More often than not however our optimisation efforts focus on pages that behave well in the vast majority of cases but are slower in a fractional few (these are usually the problems which are harder to predict). Here we will use all of the diagnostic tools at our disposal to find out what is specific to these more rare examples and then improve the code involved to better handle all scenarios.
We also sometimes find that making a subtle change in the way people use the system can bring about performance improvements. An example of this is making a task become a background process that the server can work its way through without hogging the browser, allowing users to go on to perform other tasks in the meantime. To bring our work on scalability back round full circle, we share what we have learned in our developer team meetings. Not only does this give further insight into building optimally to start with, but it’s also a forum to discuss improvements to our monitoring and diagnostic tools.