452067 - Unit test boxen are slow

Status: RESOLVED DUPLICATE of bug 474671

(Release Engineering :: General, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Recently, checking in while following the tree rules involves at least a 4-hour tree-watching commitment.  A large part of the problem is that the unit test boxes take about 1.5 hours to cycle.  As a result, you can usually expect 2-3 hours of waiting before your change cycles, and often have to wait at the beginning for the orange from previous checkins to go away.  The problem gets worse every day, as we add more tests.

Since these are not perf test boxes, there's no technical reason to use anything other than the fastest hardware we can reasonably throw at them.  Are we already doing that?  If so, do we need to split the tests up over more machines?

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Found during triage.

bz: 
1) Since we moved to using pool-of-slaves for builds *and* also unittests, in late December2008, you should not be seeing any wait times for pending unittest runs. 

2) Now that unittests are being run on the pool-of-slaves, yes, we are looking at running each unittest suite in parallel on separate machines. This should significantly reduce turnaround-time on our existing hardware. If still further improvements are needed, we could then investigate hardware upgrades. See bug#474671 for details. 


Moving to the right component for this, and closing. The pool-of-slaves work is already FIXED, so closed this as DUP of the still-to-be-done unitest-in-parallel work.