Assessing the problem
On big projects, it’s commonplace to carry on running things just as they are. “If it ain’t broke, don’t fix it”. This runs counter to one of PaperKite’s core values of “Always Be More Better”, where we believe there’s always an opportunity to make things shine.
With the addition of our new Web and Platform developer, Ellery Prisk, we had the opportunity for a developer to take a fresh look at our project processes and internal systems.
Our apps and websites are supported by our back-end services. These provide the connection between what the user sees, and the data that supports that interaction. Ellery assessed one of these services. Things that could be made better, and development issues from our backlog, were categorised using some everyday financial terminology and thinking.
“Student Loan” – “It’s there, but we can live our lives without worrying about it”
“Mortgage” – “You need to pay it regularly, but in (relatively) small amounts”
“Credit Card” – “Get it paid down as quickly as you can!”
Opening the hood of the car
Ellery realised the area of greatest impact, with some immediate “credit card” shaped items, was the database associated with the service.
For a few weeks, an automatic upgrade feature had failed to run, and development resource had had to be applied to do the work manually. He used a specialised tool called Postgres Hero, to retrieve diagnostic information about the database and how it was running.
A database stores data in tables, similar in concept to the sheets in a spreadsheet. Data is assembled in a tabular format with columns and rows.
It appeared that we had some huge database tables, with one table dominating over a third of storage. Supporting indexes for the table were larger than the size of the data it stored. These large sizes were impacting the automatic upgrade process.
Getting it fixed
On closer inspection, the database did not need to store half of the data that it had. Several of the supporting indexes were no longer used, and could be removed. Ellery completed these changes. These were then tested thoroughly in our development and pre-production environments.
Satisfied with the change, the big button was pressed to release it into production for our customers to use.
End results – 20% reduction in size
We revisited the PG Hero tool. Due to these optimisations, data storage for the table in question, was down to 20% of the size it was taking up before. Although login times were already speedy, users of the application now experience even quicker connections than before.
As our data storage is reduced, our monthly data charges have reduced as well. Our archives are now cheaper to store.
Our backup process runs quicker, and the auto upgrading process completes without manual intervention. This has freed up valuable developer time.
Living our values
At PaperKite our values are more than just words on a screen. “Always Be More Better” is our smiling take on continuous improvement, and we love to see it put in action!