Best VM Configurations for Your Specific Use Case

Getting the most out of your VM configuration while executing builds requires a fairly solid knowledge of your overall build process. While this seems obvious, there are often elements developers simply assume work one way that, in fact, do not, until a deep dive is conducted.

Pipelines

Jenkins Pipelines (or an equivalent service) will tell you a lot about your build process, but not everything. In particular, Xcode is pretty closed off when it comes to its portion, but other steps can be made clear. For example, repo pulls can easily be their own block, along with each testing piece.

Monitoring Tools

Step one is to profile your real usage. Here at MacStadium, we prefer LogicMonitor, but there are numerous OS monitoring tools you can choose from. At a high level, you want to have sufficient CPUs for your number of parallel threads, sufficient RAM to keep the operation in memory if possible, and then look at clock speed.

Tinker

After getting one good benchmark of current usage, users then need to spend some time experimenting with settings. To see if you can benefit from more CPUs, launch a VM with more CPUs than are normally used, then just check for any performance differences. Then, try to pass in usage of more cores by modifying the number of threads in use inside of your code. See if your build actually benefits from Xcode’s native parallel feature, then reduce down to see if you can get away with few cores.

For builds with a really low core count, the increased clock speed of some Apple hardware has a big benefit. While normally hardware is already selected, being aware the highest clock speed for the number of cores in use is the ideal purchase. Core count always dominates this math - a lower clock speed plus more cores equals a faster build.

Brass Tacks

Now that the build is fully profiled, you now can make an intelligent decision about if you have enough resources to run multiple builds at the same time. The first question is - can you run multiple VMs with your resources? The ideal CPUs and how much RAM is desired determines this.

If you can, then the question becomes absolute speed verses total work done. Ultimately, any additional VMs on a single node will cause that single build to take longer, but usually on the order of 5% (for Orka) or 10%-20% (for vSphere). This is because these are enterprise-grade virtualization methods, so you will produce more builds net for the performance hit on a single build.

Note using the current hypervisor of macOS, VM builds will take much longer. For Mojave, MacStadium testing with the native hypervisor showed 40%-50% increase in build times when using two VMs. (Apple is aware of that, and they are working to get their built-in hypervisor competitive).

And finally, persisting the changes in to a template your uses will pull from, then getting users to use the new template, can have its own challenges. MacStadium hopes that part is relatively easy, but…