I want to minimize the time required for the most-costly compilation step in our CI/CD environment.
Right now, We’re on GitLab using their runners to be installed on own machines. I tried with Kubernetes clusters on GCP and the Gitlab-provided runners and while this all runs fine and scales nicely horizontally, I am looking for quick build and test times. In our setup, the build step (fetching deps, comiling deps and own sources) takes the most time: a few minutes, depending on the project.
So I am looking into dedicated hardware for our gitlab runners where the major workload will be mix compile . Since the team isn’t big I don’t really need all the auto-scaling a Kubenetes cluster has to offer. I want quick result for individual builds from scratch.
Should I go many cores or for high single-core performance? Other than that I’ll go for local SSD storage and plenty of RAM (64GB).
The biggest thing when making a CI/CD fast is minimizing the work that you need to do each time. If you’re having to compile all the dependencies from scratch every time, the biggest win will come from finding a way to cache that, regardless of what CPUs are available. We have a large project, but the actual compilation step takes < 10 seconds in our CI unless we are changing a dependency.
Very True! Thanks a lot. We already cache _build until mix.lock changes. What do you do to cache? Any more insights?
We also have a lot of git submodules in place for which we currently cannot track for changes – this surely can be tweaked somehow.
Still, getting build + test done even 10 seconds faster would greatly improve the process here for a lot lot unresolved reasons circling around the testability on developer machines. And while we’re of course going to fix those problems at some point I am looking for ways to have us more productive even at this stage.
In the short term simply adding more CPU power is an option to me as we can just buy it w/o someone to make it. So again, any insights on which hardware to get?
Fair enough! The Elixir compiler is parallel, so you should be able to benefit from multiple cores. SSD speed is of course critical. 64gb of ram is wildly more than enough.
…until it hit’s compile time dependencies. So checking those and cutting them at certain places can also improve compilation times (in cached scenarios).
Tiered caches will help with the build time a lot. On CircleCI, even with small test runners, you are able to cache the hex deps, the compiled code, and PLT files if dialyzer is your thing.
I do this for all my applications, but here is an example for an open source project:
In terms of CPUs, I found the AMD Threadripper series quite good for compilation and overall dev work. Best results so far however I achieved with recent Xeon CPUs. They have bigger L1 / L2 / L3 caches than most consumer CPUs and I found them to be extremely adequate for compiling.
I’d say go for a Threadripper or a Xeon with at least 8 physical cores and a NVMe / PCI SSD (> 2 GB/s read/write speed). RAM isn’t of huge consequence for a compilation / CI machine. Even 16GB would be an overkill, unless the machine is also a dev machine and I misread you.
$ time mix compile --force
Compiling 418 files (.ex)
Generated <our_company_app> app
mix compile --force 76.51s user 16.60s system 664% cpu 14.020 total
To be honest, I expected the Elixir compiler to be able to utilise all cores.
. Since the team isn’t big I don’t really need all the auto-scaling a Kubenetes cluster has to offer. I want quick result for individual builds from scratch.
