hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Meil <doug.m...@explorysmedical.com>
Subject Re: Running UnitTests before submitting a patch
Date Mon, 19 Sep 2011 01:12:17 GMT

>From the most recent build the performance is certainly lumpy in a few
packages.

https://builds.apache.org/job/HBase-TRUNK/2232/testReport/

org.apache.hadoop.hbase.client 13 min

org.apache.hadoop.hbase.mapreduce  9 min 42 sec
org.apache.hadoop.hbase.master  7 min 14 sec
org.apache.hadoop.hbase.regionserver 7 min 42 sec

org.apache.hadoop.hbase   4 min 41 sec



These 5 packages are responsible for about 60% of this unit-test run (1hr
11mins).


And in each one of these packages there are lumps, such as this in client

testHundredsOfTable  2 min 14 sec


My guess is that a lot can be done with a targeted effort (I.e., targeted
refactoring, not changing every single unit test).

Yes, sign me up.


On 9/18/11 3:28 PM, "Stack" <stack@duboce.net> wrote:

>On Fri, Sep 16, 2011 at 11:39 PM, Akash Ashok <thehellmaker@gmail.com>
>wrote:
>> Firstly I end up running the whole suite without a the patch  and second
>> with patch and compare the results. But it turns out most of the times
>> there's always inconsistency. Meaning to say a few tests are erratic.
>>The
>> fail while running the whole suite and pass when run alone. Moreover
>>running
>> the whole test suite takes about 2 hours.
>>
>> This is taking a lot of time for me to work on the simplest of the
>>patches.
>>
>
>Yes, this is a problem.  That the tests take so long to run, I'm sure,
>is a barrier to contribution.   It also in part explains why our test
>builds are so often red -- because its onerous running full suite.  We
>used to huff and puff about the fact that our test suite took an hour.
> I hadn't realized we were beyond the two hour mark now.  Need to work
>on this.  Will file some issues for the longer-running tests.  Some we
>can aggregate.  Whats really needed are better tools and more use of
>Interfaces so the parts not under test can be mocked rather than have
>to stand up real instances of an hdfs or mapreduce cluster.  Need to
>work on this too.
>
>That our test suite is seen to be flakey doesn't inspire confidence
>and makes it so you do the crazy thing of having to run once to see
>what the current state is before you apply your patch (two hours
>later).  This should start to improve at least on the branch when we
>start to work on stabilization.
>
>At a place I used to work, if you broke the build you were given a
>giant purple barney -- http://www.barney.com/usa/index.asp -- and you
>had to wear it on your desk until someone else broke the build and
>then you could pass it off.  The contortions fellas went through to
>avoid being barney-ified were monstrous.  We need something like a
>virtual barney for hbase.  Suggestions?
>
>St.Ack


Mime
View raw message