|
|
Boost Testing : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-09-28 08:00:00
Rene Rivera wrote:
> I've been watching my Linux machine take incrementally more and more
> time processing the regression results and uploading them to the OSL
> server. If I'm lucky not too many new results come in, and it takes 3.5
> hours (it used to take about half that). Still not entirely bad... But
> the really bad part is that the generated results, which are compressed
> into a ZIP file, takes more than 200M. It takes a long time to upload
> that through my limited pipe. So I'm looking for suggestions on how to
> improve the turn around time, and of course suggestions on how to reduce
> the over all resources needed are welcome... Note, I'm looking for
> things we can do quickly.
>
> The one though I've had so far is to use "rsync" instead of uploading a
> ZIP, and them zipping on the OSL server. But the uncompressed sources
> are more than 1.5Gig so it would make for close to 2Gig of disk space
> use on the OSL server. Which is something I'd rather avoid.
>
> So, any clever ideas out there?
Divide and conquer
==================
Partition the runners into three groups, to be processed and reported
separately:
* Trunk/Release compilers only. Cycle tests and reporting very often.
Many times a day if possible. Runners by invitation only.
* Release branch/Release compilers only. Cycle tests and reporting
fairly often, say two to four times a day. Runners by invitation only.
* Trunk/All other compilers. Cycle tests and reporting less often. Once
or twice a day. All runners accepted.
Rationale
=========
* Splits the workload, allowing the report processing to be distributed
to several machines.
* Speeds report processing, given the non-linear nature of the XSLT
processing.
* Speeds testing and reporting for the platforms developers and release
managers care most about.
* Makes knowing if a library passes for a release platform far more
explicit. That's been a problem for release managers.
--Beman