[
https://issues.apache.org/jira/browse/HDFS-12277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126364#comment-16126364
]
Michael Han commented on HDFS-12277:
------------------------------------
Thanks for review, Andrew. Thinking again, it also makes to me to keep the
existing semantic which finds the saturation breakpoint of the (hopefully)
linear correlation between client concurrency and server throughput. I'll add
throughput per thread which can be used to calculate latency per operation in a
separate JIRA.
> NNThroughputBenchmark should use cumulativeTime to calculate ops per second.
> ----------------------------------------------------------------------------
>
> Key: HDFS-12277
> URL: https://issues.apache.org/jira/browse/HDFS-12277
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: benchmarks, tools
> Reporter: Michael Han
> Assignee: Michael Han
> Priority: Minor
> Attachments: HDFS-12277.000.patch, HDFS-12277.001.patch
>
>
> {{NNThroughputBenchmark$getOpsPerSecond}} is using {{elapsedTime}} to
> calculate ops per second. {{elapsedTime}} is the time used to measure the
> time from the start to the finish of the benchmark main thread, and it's also
> the total execution time of the single slowest benchmark worker thread. To
> measure ops per second, we should use the total execution time of all worker
> threads, which is {{cumulativeTime}}. Otherwise, we could get bogus result,
> e.g. given same load, the more client threads we have (controlled by
> {{-threads}}), the larger ops per second the number would be, with the same
> NN and its server side configurations.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
