Hello,

Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 733.972 sec

That's 12 minutes, not far from the current timeout for a single test
(900 seconds).
Is there anyone working on this or adding new tests there?
As you know,  if the test takes more time because there are new tests
in it, it makes sense to break it in smaller pieces to get some
parallelization.

I've seen as well these ones:
Running org.apache.hadoop.hbase.backup.example.TestZooKeeperTableArchiveClient
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 284.153 sec

Running org.apache.hadoop.hbase.io.encoding.TestChangingEncoding
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 299.748 sec

I had a look at this last one, hopefully it will be reduced by 100s
after HBASE-6654.

Still, there is a lot of tests around the 3+ minutes execution time.
It's better to stick to less than 1 minute as much as we can... If
even worth checking this area during the code review I would say.

Cheers,

Nicolas.

On Fri, Aug 24, 2012 at 6:54 AM, N Keywal <[EMAIL PROTECTED]> wrote:

>
> I've seen as well these ones:
> Running
> org.apache.hadoop.hbase.backup.example.TestZooKeeperTableArchiveClient
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 284.153 sec
>
> This one was me. It does a bunch of waiting for compactions to preceed via
the high level API and also coordination via ZK (so full cluster setup/down
is included in the test time).

There is a forced sleep (currently 1000ms) but that is a far smaller than
the overall runtime. It just that compactions seem to take a while. I can
take a look early next week though if we really want to crank down the time
- it is categorized a Large though...

-Jesse

Hi Jesse,

Yes, I tried, reducing the sleep does not change much the test time :-).

I took these two as example, as 5 minutes seemed to be a lot to me (with
the current config, it slows down the global build by  more than 1 minute
alone), and I think it's easier to tackle this at the very beginning. After
a year or two, when many contributors added tests, fixed bugs and so on,
it's more difficult to change things: you always fear that you're going to
decrease the test coverage. And it may requires to change the main code to
ease hooking/mocking & so on. It's obviously easier to do during the dev
than post dev...

Cheers,

Nicolas
On Fri, Aug 24, 2012 at 9:07 PM, Jesse Yates <[EMAIL PROTECTED]>
wrote:
> On Fri, Aug 24, 2012 at 6:54 AM, N Keywal <[EMAIL PROTECTED]> wrote:
>
>>
>> I've seen as well these ones:
>> Running
>> org.apache.hadoop.hbase.backup.example.TestZooKeeperTableArchiveClient
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 284.153
sec
>>
>> This one was me. It does a bunch of waiting for compactions to preceed
via
> the high level API and also coordination via ZK (so full cluster
setup/down
> is included in the test time).
>
> There is a forced sleep (currently 1000ms) but that is a far smaller than
> the overall runtime. It just that compactions seem to take a while. I can
> take a look early next week though if we really want to crank down the
time
> - it is categorized a Large though...
>
> -Jesse

>
> it's more difficult to change things: you always fear that you're going to
> decrease the test coverage.
And the joys of reliance on a test suite.
> And it may requires to change the main code to
> ease hooking/mocking & so on.
Far easier said than done. I should have some time in Sept to work on
generally fixing this, but I'll work towards it with an eye on fixing the
slower tests.
> It's obviously easier to do during the dev
> than post dev...
>
> Cheers,
>
> Nicolas
>
>
> On Fri, Aug 24, 2012 at 9:07 PM, Jesse Yates <[EMAIL PROTECTED]>
> wrote:
> > On Fri, Aug 24, 2012 at 6:54 AM, N Keywal <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> I've seen as well these ones:
> >> Running
> >> org.apache.hadoop.hbase.backup.example.TestZooKeeperTableArchiveClient
> >> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 284.153
> sec
> >>
> >> This one was me. It does a bunch of waiting for compactions to preceed
> via
> > the high level API and also coordination via ZK (so full cluster
> setup/down
> > is included in the test time).
> >
> > There is a forced sleep (currently 1000ms) but that is a far smaller than
> > the overall runtime. It just that compactions seem to take a while. I can
> > take a look early next week though if we really want to crank down the
> time
> > - it is categorized a Large though...
> >
> > -Jesse
>

On Sat, Aug 25, 2012 at 6:11 PM, Jesse Yates <[EMAIL PROTECTED]>wrote:

> >
> > it's more difficult to change things: you always fear that you're going
> to
> > decrease the test coverage.
> And the joys of reliance on a test suite.
>

:-)

> And it may requires to change the main code to
> ease hooking/mocking & so on.

> Far easier said than done.
Fully agreed.
> I should have some time in Sept to work on
> generally fixing this, but I'll work towards it with an eye on fixing the
> slower tests.
>

Thanks for this, Jesse.

Have a nice week-end,

N.

On Fri, Aug 24, 2012 at 6:54 AM, N Keywal <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
> Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 733.972 sec
>
> That's 12 minutes, not far from the current timeout for a single test
> (900 seconds).
> Is there anyone working on this or adding new tests there?
> As you know,  if the test takes more time because there are new tests
> in it, it makes sense to break it in smaller pieces to get some
> parallelization.
>
> I've seen as well these ones:
> Running org.apache.hadoop.hbase.backup.example.TestZooKeeperTableArchiveClient
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 284.153 sec
>
> Running org.apache.hadoop.hbase.io.encoding.TestChangingEncoding
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 299.748 sec
>
> I had a look at this last one, hopefully it will be reduced by 100s
> after HBASE-6654.
>
> Still, there is a lot of tests around the 3+ minutes execution time.
> It's better to stick to less than 1 minute as much as we can... If
> even worth checking this area during the code review I would say.
>

Good point N.  I like idea of checking test length as part of review.

The above tests are mostly new I believe.  We should have done better
job looking out for long-running tests.  I'd say file an issue on the
12minuter.  That should be cut way down or just moved out to be an
out-of-bound Integration test.

St.Ack

Done: HBASE-6655

I was thinking about a hard option: changing the fork timeout on build
with the profile "runAllTests". Today is 15 minutes, at the beginning
I would make it around 10 minutes, but with a progressive target of 5
minutes or so. This way, whatever takes too long will be VERY visible.
When running a single test, it would be longer, allowing the user to
debug or monitor as much as he wants...

On Fri, Aug 24, 2012 at 5:27 PM, Stack <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 24, 2012 at 6:54 AM, N Keywal <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
>> Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 733.972 sec
>>
>> That's 12 minutes, not far from the current timeout for a single test
>> (900 seconds).
>> Is there anyone working on this or adding new tests there?
>> As you know,  if the test takes more time because there are new tests
>> in it, it makes sense to break it in smaller pieces to get some
>> parallelization.
>>
>> I've seen as well these ones:
>> Running org.apache.hadoop.hbase.backup.example.TestZooKeeperTableArchiveClient
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 284.153 sec
>>
>> Running org.apache.hadoop.hbase.io.encoding.TestChangingEncoding
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 299.748 sec
>>
>> I had a look at this last one, hopefully it will be reduced by 100s
>> after HBASE-6654.
>>
>> Still, there is a lot of tests around the 3+ minutes execution time.
>> It's better to stick to less than 1 minute as much as we can... If
>> even worth checking this area during the code review I would say.
>>
>
> Good point N.  I like idea of checking test length as part of review.
>
> The above tests are mostly new I believe.  We should have done better
> job looking out for long-running tests.  I'd say file an issue on the
> 12minuter.  That should be cut way down or just moved out to be an
> out-of-bound Integration test.
>
> St.Ack

On Fri, Aug 24, 2012 at 9:02 AM, N Keywal <[EMAIL PROTECTED]> wrote:
> Done: HBASE-6655
>
> I was thinking about a hard option: changing the fork timeout on build
> with the profile "runAllTests". Today is 15 minutes, at the beginning
> I would make it around 10 minutes, but with a progressive target of 5
> minutes or so. This way, whatever takes too long will be VERY visible.
> When running a single test, it would be longer, allowing the user to
> debug or monitor as much as he wants...
>

lol

Thats funny.

I like the idea.

St.Ack