Lately I’ve been working on integrating BuildForge with TFS Team Build. One feature missing in Team Build v2 is the ability to automatically load balance build servers. Hey Microsoft, DefaultBuildAgent=FirstAvailable would be REALLY cool!
Fortunately BuildForge has a useful ability to define a pool of build machines that meet a set of criteria ( Selectors and Collectors ) and then specify how many concurrent builds can run at a time ( _MAXJOBS=xx). With a little bit of plumbing I can use BuildForge as a bootstrapper to kick off Team Build’s across a build farm.
Way Cool! But how’s the performance? The numbers above were taken using an HP DL-380 G5 with 3.0GHZ Xeon, 16GB of RAM and a SAS RAD5 storage running Server 2008 Hyper-V. Not the fastest machine in the world but it’ll do. Each build represent a small .NET 3.5 Windows Services project that also builds an InstallShield Merge Module and Product Installer.
As you can see, when running consecutively each individual build is about 30% faster. However when you compare the overall throughput the concurrent builds are nearly 3x faster!
Of course the real beauty is that this system is now scalable to N number of virtual build servers. Just drop another hypervisor in the rack, fire up some VM’s and add them to the collectors.
How’s that for a little zoom zoom zoom?
As an aside, I was monitoring the performance and I could see that I was DISK I/O bound. CPU and memory was fine.