[
https://issues.apache.org/jira/browse/NIFI-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15129662#comment-15129662
]
ASF GitHub Bot commented on NIFI-1460:
--------------------------------------
Github user trkurc commented on the pull request:
https://github.com/apache/nifi/pull/202#issuecomment-178965345
> But, do you think that should be accounted against the manageability of
the method in context of the provided test scenario?
I'm not sure I'm following. To give you an idea of my thought process with
2, "if we're going for maximum speed, changing the method signature, and
avoiding some boxing would be ideal".
However, it was the latter part of my claim about 3 being "performant
enough" and not dependent on a RNG, and still a "UUID" which I thought more
thought provoking - fast enough, potentially less tech debt, everyone wins?
> Test Performance improvement. Test Timeout Mitigation.
> ------------------------------------------------------
>
> Key: NIFI-1460
> URL: https://issues.apache.org/jira/browse/NIFI-1460
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Tools and Build
> Affects Versions: 0.4.1
> Environment: linux, unix with true random number generator.
> Reporter: Puspendu Banerjee
> Priority: Minor
> Labels: performance
> Fix For: 0.5.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Existing test case
> nifi-framework-core/src/test/java/org/apache/nifi/controller/TestStandardFlowFileQueue.java
> uses a huge number of call to UUID.randomUUID() which is very slow in linux
> , unix environment if there is not much activity [ like mouse move etc.] .In
> addition to that UUID.randomUUID() depends on /dev/(u)random to get a random
> number, such system call costs IO and /dev/random is bandwidth/rate limited
> which again slows down overall performance.
> Workaround is rngd daemon(ref: http://linux.die.net/man/8/rngd)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
