Today we've pushed live an update to the API that improves performance and we wanted to talk about it. Over the past two months we've been evaluating every aspect of the service to locate performance bottlenecks and correct them. You may have seen this blog post we made on April 10th about this where we changed a lot of things related to storing customer data and the customer dashboard.

That work has been ongoing, and we've been squashing bugs and handling edge cases that resulted from those changes. We've also been rewriting significant parts of our data synchronisation system, and as a result, we've been able to significantly lower CPU usage on all our servers. Essentially, our servers now spend less CPU time on database stuff so they can put more resources into answering your API queries.

However, there was one area we had not changed in a while. In this blog post from November 2022 we mentioned how we were preparing to deploy PHP v8.2. We did deploy PHP v8.2 on both the API and our website the following month. However, we've stuck with PHP v8.2.x versions since then. Meanwhile PHP v8.3 and now v8.4 have been released and we were lagging behind. To be clear we still used a supported version of PHP that has been receiving security patches and bug fixes, but we weren't using the latest major versions that contain improvements to the language, new features and crucially for us, extra performance.

Today however that all changes as we've upgraded all the way to PHP v8.4.7 the very current release and in doing so we've improved API response times. Previously for our servers that achieved an average of 5.7ms internal processing time (network overhead not included), we've been able to lower that to an average of 4ms. While this isn't a lot in time terms as a percentage that's a 29.8% reduction in average compute time.

In addition to upgrading to PHP v8.4.7 across the entire site (our Dashboard and other pages will also benefit from these speedups and in fact, should benefit even more than the API due to their larger footprints) we've also been optimising the API itself. We've eliminated two disk read operations which checked for the existence of data that no customers made use of, these reads had nanosecond level impacts but extrapolated across all the queries we handle it adds up.

Similarly to the above optimisation, where we couldn't eliminate a disk read we instead moved the data to our in-memory data store system. Accessing data from memory is much faster than from storage disks (even though we exclusively use NVMe SSDs) and it allows for higher throughput of the API by not needing to wait on storage queues. In fact, our in-memory data store is fully multithreaded and non-blocking too. We were able to offload three separate database reads from disk to memory with this change and at least two of these are used by every single query to the API.

We've done extensive testing to make sure these changes especially the move to PHP v8.4.7 are fully tested. We performed millions of varied queries against the API and tested all our web pages and most of the functions within those pages before pushing it live. As always though it's possible we missed something so if you notice anything not working correctly please contact us, we do respond to every communication we receive.

So that's the update for today, lots of performance improvements and a major server-side code interpreter update, thanks for reading and have a wonderful week!