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.
1 comment:
We agree, and for the next release we've already added the feature to pick the first available build server. We've also built in the ability to specify how many builds can run concurrently on a single machine.
Buck
Post a Comment