hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <lhofha...@yahoo.com>
Subject Re: small perf degradation in 0.94 trunk vs. older versions
Date Wed, 28 Nov 2012 22:02:28 GMT
Did a quick scan through the changes committed since 0.94.1:


Any chance you can do this again with 0.94.2 (or even do a binary search through the commits
to pinpoint the change)?

-- Lars

 From: Nicolas Liochon <nkeywal@gmail.com>
To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com> 
Sent: Tuesday, November 27, 2012 10:42 AM
Subject: Re: small perf degradation in 0.94 trunk vs. older versions

It was Version 0.94.3, r38dbd22c99debd9010e9e5f4fbabeeaf3c4e1ddd

On Tue, Nov 27, 2012 at 7:41 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:

Interesting. Thanks N.
>I'll look through the 0.94 commits since 0.94.1 to see what's causing this.
>With 0.94 trunk you mean the 0.94.3RC?
>-- Lars
> From: Nicolas Liochon <nkeywal@gmail.com>
>To: dev@hbase.apache.org
>Sent: Tuesday, November 27, 2012 5:07 AM
>Subject: small perf degradation in 0.94 trunk vs. older versions
>On a create table / reassignment, I feel we lost some performances recently
>on 0.94. It's not huge (5% to 10%), but I would prefer them to be the other
>way around.
>Here are some tests I've done on test cluster, all the time with Hadoop
>scenario: 2 RS. Create a table with 3000 regions.
>Start a third RS. Kill -15 the second one: there are 1500 regions to
>I've made multiple measures, there are all there:
>It's in seconds.
>Creating a table with 3000 regions:
>0.92: 261s; 260s
>0.94.0: 260s; 260s
>0.94.1: 261s; 260s
>0.94 trunk: 292s; 281s; 282s;
>0.96 trunk: 173s; 178s
>Reassign after the kill
>0.92: 107s, 110s
>0.94.0: 105s; 105s
>0.94.1: 107s; 107s
>0.94 trunk: 122s; 105s; 116s
>0.96 trunk: 50s; 50s;
>I don't know if there is a reason the the 0.94 trunk results...
>The results for 0.96s are actually not that great, my tests (on a single
>machine) were much better a few months ago. I will look at that.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message