One of our development teams highlighted that their build was taking too long to run. We obtained a near three times speed improvement in most part by using newer AWS instance types and allocating fewer Buildkite agents per CPU. Envato use the excellent Buildkite to run integration tests and code deployments. As a bring-your-own-hardware platform, […]
One of our development teams highlighted that their build was taking too long to run. We obtained a near three times speed improvement in most part by using newer AWS instance types and allocating fewer Buildkite agents per CPU.
Envato use the excellent Buildkite to run integration tests and code deployments. As a bring-your-own-hardware platform, Buildkite offers us a lot of flexibility in where and how these tasks run.
This means that we’re able to analyse how that build is using its hardware resources and try to work out a better configuration.
The build in question is for the “Market Shopfront” product: a React & node.js application written in TypeScript, built with webpack, and tested using Jest and Cypress.
On-branch builds were taking between ten to twenty-five minutes.
master builds, which also include a separate build of a production container and a deploy to a staging environment, were taking between fifteen and forty minutes.
Builds should take less than five minutes: any longer and the waiting for a build becomes a reason to switch to something else, forcing an expensive context switch back once the build has finished. Worse, a consistently failing build can easily consume an entire day, especially if it’s only repeatable in CI.
The efforts described below are one part of a larger project to improve this build’s performance and use what we learned to improve other builds at Envato.
The first thing that stood out to me was the very high variance in build times. This hinted either that:
The first possibility was quickly ruled out: the parts of the build that talk to things on the internet or in AWS showed the same level of variance as other parts of the build that are entirely local.
We don’t (yet) have external instrumentation on the build nodes, so we ssh’d into them individually and used the
sysstat toolkit to watch the instance’s performance. We found that CPU was almost entirely utilised while memory, disk bandwidth, disk operations per second, and network throughput still had a fair amount of headroom. We also found that the CPU being fully utilised by concurrent builds on the same node was the cause of the large variance in build times.
This confirmed what several people in the team already suspected: we needed more CPU.
Dedicated spot fleets and Buildkite queues were created to perform indicative testing on the effect of different node configurations and classes on build performance.
The existing configuration was
m3.xlarge spot instances with one agent per AWS virtual CPU.
We found that:
c5instances was minimal
z1dinstances provided a further 30% performance increase, but at double the cost
docker pullcache layers, which randomly increased build times
However, these results and findings are indicative only: only one sample was taken for each instance class.
We isolated two steps from the build that were not network-dependent and were idempotent: the initial webpack build and the first set of unit tests. They were run multiple times using the avgtime utility on a set of instance types:
This confirmed (at least, for these two steps) the indicative findings on the performance improvements offered by the newer instance types:
m5 instances are approximately 50% faster than their older
c3 counterparts for this type of work. It is also interesting that
m5 instances are almost exactly as fast as each other for this step, despite the
c5’s reported 3ghz versus the
AWS advertises its instances as having a certain number of “virtual CPUs” or vCPUs. This can be misleading if you’re not already familiar with Intel’s Hyperthreading, where for every processor core that is physically present, two “logical” cores are made available to the operating system. AWS’ vCPUs map directly to logical cores, not physical ones,
Our instances were configured to run one agent per logical core, not physical. This meant that even single-threaded build steps could take up to twice as long to run if the instance’s CPU was fully taxed. This was originally a cost saving measure that was based on the assumption that most build steps would spend their time waiting on network resources or other tasks. For this build queue this assumption proved to be incorrect.
We ran two benchmarks on a single
c3.large: one with a single webpack build running, and one with two running in parallel. We also ran the same benchmark on a
c5.large to determine whether the newer instance type provided better Hyperthreading optimisations:
On both classes of instance, running two identical steps at the same time on the same physical CPU nearly doubled the execution time versus running only one, despite the benefits offered by Hyperthreading.
All of the tests above were run via
docker run on a container without volumes or bind mounts:
node_modules and the project’s source were baked into the image via
COPY . /app. Running the webpack build with these files instead bind mounted (via
-v $(pwd):/app) showed us a significant performance improvement:
Unfortunately, this isn’t something that we can easily take advantage of in our builds without making them significantly more complicated. Bind mounts also gave us no performance improvements when running the unit test step.
Based on the above results, we decided on two initial actions:
We opted for the
d class instances as we wished to keep using the instance storage provided by the
m3 class instances. Doubling the instance size while halving the number of agents per virtual CPU meant that we still had the same number of agents per spot instance, meaning that we’d increase build performance without increasing cache misses on docker image layers.
This was recorded as a set of Architectural Decision Records in the git repository containing the StackMaster configuration for this fleet so that future maintainers would know the context and thinking behind these changes.
Prediction of how much this would increase costs was difficult: we anticipated that while each individual instance cost twice as much, we’d ultimately need less of them, as faster builds would mean that the spot fleet autoscaling rules would be triggered less frequently. We expected that the change would increase costs as our fleet is configured to always have one instance running regardless of load, and we’d be doubling that instance’s size.
We found that the change more than doubled the cost for this fleet: the newer instance types are in higher demand and therefore attract higher spot prices. Fortunately for us the original costs were very low, so this level of increase was not a big worry!
This change had an almost immediate and significant effect on branch builds, as shown in the scatter plot below in the middle of November. Master builds have also improved, but less so, as the deploy to staging adds a significant chunk of time:
Through this change builds have become both much faster and much more consistent: branch builds that previously took between ten and twenty five minutes now take between four and ten, and master builds that took between fifteen and thirty five minutes now take between seven and thirteen.
Other improvements have been made to this build, but of all of them it was this change that had the highest impact. We’re now hoping to take what we’ve learned here and roll it out to a single consolidated fleet of agents that can be shared by all projects, rather than a single fleet per project. This will allow us to consider faster instance types (like the lighting-fast
z1d instances) as we’ll have less “idle” agents, offsetting costs.
Eagle-eyed readers will notice that the times in the scatter plot above are faster than the speculative improvements we expected in our initial runs. The above improvements aren’t the whole story, just the change we made with the highest impact: additional improvements were made in our webpack configuration, balancing of E2E tests between nodes, and docker layer caching strategies.
More on these further changes soon!