English | EN 
Last year, I was privileged to participate in Sogeti’s Lead Technologist program, which comprised of a series of insightful training workshops and a project.
It was revealed, about halfway through the course, that the topic of the project was “Sustainability”, and this reveal filled me, if I am being perfectly honest, with a certain degree of dread. Sustainability is a very hot topic and deep-down I know we all need to focus on it. In this article, I hope to share parts of my journey with you and show you that there is something we can do to start to help improve corporate sustainability, and it’s something we can do already!
My initial dread was, you may not be surprised to learn, largely unfounded. The challenge we were set was to come up with an idea which would help improve sustainability, as presented to us by our Head of Sustainability, who has a long list of credentials and years of experience in sustainability. My fears centered on wondering if there was anything we could possibly do which he’d not already considered and actioned!
Thankfully, through determined teamwork, our Sogeti Led Technologist cohort came up with a list of ideas for our project which we were able to refine down to a single choice. After a few fits and starts, and a distinct but clear trip through the Doldrums, we successfully delivered something that met the brief. I’ll leave it that, as it’s not the main topic of this blog, merely a source of my inspiration.
I’d like to present to you two cases where performance testing and performance tuning can help improve sustainability with only minimal impacts on your overall estate.
Firstly, let us assume you have a database which is accessed by 100 people through a working day, each searching for information, such as a customer’s contact details, and your hypothetical company has 100,000 customer records to sift through for each search.
With each search the database machine must compare what you are searching with against customer records until it finds a match. If this search is linear then the search simply starts at the first record and processes sequentially until it finds the desired data. The average number of comparisons required in this example is N, the number of records, divided by 2, or 50,000 comparisons.
Allowing for a system concurrency of 10%, then there are 10 searches against the database at any one time.If each search takes approximately 2 seconds, then we can simply multiply out the total number of comparisons per day:
| Records | Searches per Hour | Comparisons Per hour | Hours per day | Comparisons per day |
| 100,000 | 18,000 | 900,000,000 | 7 | 6,300,000,000 |
But what if there was a better way to do this? A binary search would reduce the number of comparisons significantly.
| Records | Searches per Hour | Comparisons Per hour | Hours per day | Comparisons per day |
| 100,000 | 18,000 | 298,974 | 7 | 2,092,818 |
Making this simple change to use a binary search algorithm would reduce the number of comparisons, or computations, the database server would have to make to less than 1% of the comparisons using a linear search algorithm. That means you could deploy a smaller database server that consumes less power, reducing your carbon footprint.
And the best news? The more records you have in your database, the better the comparative results become between using a linear search algorithm in comparison with a binary search algorithm!
Similarly in this example the searches occur during a traditional nine-to-five hours which means the system could be idle from five-to nine, or 16 hours a day. If we assume it may be imprudent to shut down the system off overnight then a combination of volumetric modelling and performance testing could help shape an autoscaling solution. This would make your production environment respond to both increases and decreases in demand.
This impact of this is that you would only pay for the computing to require, lowering your costs and reducing your carbon footprint further.
Performance testing could also help identify opportunities to introduce caching, where search results are stored in memory in the short term for re-use, preventing database activity.
The examples here are arguably low-hanging fruit, but they were used to demonstrate how performance testing can help increase efficiency. It’s not just about whether a search is ‘fast enough’, but also whether the system is using excessive resource to achieve the desired results.
