[jira] [Comment Edited] (HBASE-21256) Improve IntegrationTestBigLinkedList for testing huge data

["Zephyr Guo (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-21256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633164#comment-16633164 ] 

Zephyr Guo edited comment on HBASE-21256 at 9/30/18 12:42 AM:
--------------------------------------------------------------

[~Apache9]

After saw that page, I seem understand you means. If the first 32-bits is same, then all 128-bits will be same.Could we solve it in other ways? What about the following solution?
{code:java}
  random bytes   nanoTime   map taskID   iteration
|----48bits----|--64bits--|----8bits---|---8bits---|{code}
It seems that we don't need to care about collision.

 


was (Author: gzh1992n):
[~Apache9]

After saw that page, I seem understand you means. If the first 32-bits is same, then all 128-bits will be same.Could we solve in other ways? What about the following solution?
{code:java}
  random bytes   nanoTime   map taskID   iteration
|----48bits----|--64bits--|----8bits---|---8bits---|{code}
It seems that we don't need to care about collision.

 

> Improve IntegrationTestBigLinkedList for testing huge data
> ----------------------------------------------------------
>
>                 Key: HBASE-21256
>                 URL: https://issues.apache.org/jira/browse/HBASE-21256
>             Project: HBase
>          Issue Type: Improvement
>          Components: integration tests
>    Affects Versions: 3.0.0
>            Reporter: Zephyr Guo
>            Assignee: Zephyr Guo
>            Priority: Major
>             Fix For: 3.0.0
>
>         Attachments: HBASE-21256-v1.patch, HBASE-21256-v2.patch, ITBLL-1.png, ITBLL-2.png
>
>
> Recently, I use ITBLL to test some features in our company. I have encountered the following problems:
>   
>  1. Generator is too slow at the generating stage, the root cause is SecureRandom. There is a global lock in SecureRandom( See the following picture). I use Random instead of SecureRandom, and it could speed up this stage(500% up with 20 mapper).  SecureRandom was brought by HBASE-13382, but speaking of generating random bytes, in my opnion,
>  it is the same with Random.
> !ITBLL-1.png!
> 2. VerifyReducer have a cpu cost of 14% on format method. This is cause by create keyString variable. However, keyString may never be used if test result is correct.(and that's in most cases). Just delay creating keyString can yield huge performance boost in verifing stage.
> !ITBLL-2.png!
> 3.Arguments check is needed, because there's constraint between arguments. If we broken this constraint, we can not get a correct circular list.  
>   
>  4.Let big family value size could be configured.
>  
> 5.Avoid starting RS at backup master



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)