Faster Websites and Lower Infrastructure Spend

I’ve been building websites for more than 25 years and things have changed dramatically since those days. In the early days we were on slow internet connections, browsers that would display pages in wildly different ways depending on the version, operating system, and what day of the week it was. PHP was in it’s early years and not the language it is now – there were no frameworks, no build pipelines or automated testing. Speed optimization was a big part of building a site – but somewhere along the way it has become less important to many websites.

In the age of the cloud – you can click a button to spin up a server, launch a hundred virtual workstations for employees, have an instant database at your disposal, or even provision access to a satellite. Tools like WordPress empower hundreds of millions of people to update their website without the need to write code or learn complex software. The cost of this convenience can come in the form of waste spend on cloud or bloat in software code.

There was an estimated 32% overspend on cloud computing in 2022 – and it has only gone up since. I’m not just talking to about servers sitting idle and going unused – I’m also talking about systems being architected and code being written that are highly inefficient and using more resources than needed. There is an entire market of WordPress optimization tools out there because with the convenience of WordPress comes the risk of creating a beautiful website that is bloated and wasteful of resources.

A couple of recent examples come to mind:

A client is using DynamoDB and Solr on AWS. We took a look at their situation and we found an opportunity to reduce the demand on DynamoDB by strategically caching a few additional pieces of data in their already existing Solr index. This wouldn’t lead to increased requests to Solr because it was already being used – but it removed the need to hit DynamoDB as frequently. This immediately reduces the monthly spend on DynamoDB and it also led to their pages loading anywhere from 200-300ms faster.

This is a big win for the client because it saves them money and gets their pages in front of their customers faster. It is also a win for Airtight Design because we get to deliver that value to our client – which is why we do what we do.

Another recent example involved a client that was using rsync to mirror data files between multiple data centers. The customer has a lot of data that needs to be synced and backed up between multiple physical locations. There were an array of file servers all running multiple threads of rsync commands all day, every day. Some of the file servers were older and didn’t receive as much new data every day, but they were using a ridiculous amount of bandwidth. This was our clue that something was wrong.

Airtight identified that the rsyncs themselves were creating the bandwidth overhead by running too often. On our redocumentation, the customer scaled back to single threads and introduced a ten minute delay between rsyncs. This took what was a fully saturated 1Gbps pipe and reduced it by 40-60% depending on time of day. The most impactful reduction was in the data sync to AWS as pictured below. This reduction was huge compared to the overall pipe. Before Airtight discovered the problem with rsyncs, the customer was considering adding additional bandwidth to their data centers. Now they don’t have to and this has saved our client an estimated $10,000 a year. Everything between their data centers is still being synced up, but without the noise of rsync wasting bandwidth.

Airtight Design is committed to building efficient, powerful websites that meet each of our clients’ unique needs.