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

Duo Zhang commented on HBASE-21256:
-----------------------------------

Hey [~stack] I've relied on review board, that the likelihood of collision is 
related to the length of the period.

The period for the java Random class is 2^48, which means that when you start 
from 48 bits integer, after 2^48 times you will get this integer again. And 
since we use 32 bits integer, which is the lowest or highest 32 bits for the 48 
bits integer, it will be more likely to collision.

And the period of the new Random64 is 2^64, and we will use the 64 bits long to 
generate keys, the likelihood of collision will be very very small.



> 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, 
> HBASE-21256-v3.patch, HBASE-21256-v4.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)

Reply via email to