[
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)
