[
https://issues.apache.org/jira/browse/IGNITE-29147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Davydov updated IGNITE-29147:
------------------------------------
Description:
The JMH benchmarks in {{modules/benchmarks}} start the client and server nodes
in the benchmark JVM. JMH's {{-prof gc}} reports one bytes-per-operation number
for that whole JVM, so it can't show on which node or in which thread pool a
change adds allocation. It also undercounts the last iteration: the benchmarks
stop their nodes in the trial teardown, which JMH runs before profilers read
the last iteration, so the bytes of the stopped nodes are lost.
This adds:
* {{JmhAllocationProfiler}}, a JMH profiler ({{-prof}}) that reports bytes
allocated per operation by the benchmark threads and by each thread pool of
each node, client or server. It also reports communication messages and bytes
sent, and discovery messages processed, per operation and node. Threads are
grouped by the node and pool in their names.
* {{JmhNodeStopHook}}. {{JmhCacheAbstractBenchmark}} calls it before stopping
its nodes, so profilers see the last iteration.
* {{JmhCacheAllocationBenchmark}}: cache put and get on atomic and
transactional caches, through a client node with two server nodes, run with the
profiler from its {{main()}}.
* A README for the module: what the benchmarks measure, how to build and run
them, how to measure allocation and how to write a benchmark.
All changes are in {{modules/benchmarks}}.
was:
The JMH benchmarks in {{modules/benchmarks}} start the client and server nodes
in the benchmark JVM. JMH's {{-prof gc}} reports one bytes-per-operation number
for that whole JVM, so it can't show on which node or in which thread pool a
change adds allocation. It also undercounts the last iteration: the benchmarks
stop their nodes in the trial teardown, which JMH runs before profilers read
the last iteration, so the bytes of the stopped nodes are lost. In a cache put
benchmark the last iteration drops from about 4,970 to about 1,080 B/op.
This adds:
* {{JmhAllocationProfiler}}, a JMH profiler ({{-prof}}) that reports bytes
allocated per operation by the benchmark threads and by each thread pool of
each node, client or server. It also reports communication messages and bytes
sent, and discovery messages processed, per operation and node. Threads are
grouped by the node and pool in their names.
* {{JmhNodeStopHook}}. {{JmhCacheAbstractBenchmark}} calls it before stopping
its nodes, so profilers see the last iteration.
* {{JmhCacheAllocationBenchmark}}: cache put and get on atomic and
transactional caches, through a client node with two server nodes, run with the
profiler from its {{main()}}.
* A README for the module: what the benchmarks measure, how to build and run
them, how to measure allocation and how to write a benchmark.
All changes are in {{modules/benchmarks}}.
> Add allocation profiler to JMH benchmarks
> -----------------------------------------
>
> Key: IGNITE-29147
> URL: https://issues.apache.org/jira/browse/IGNITE-29147
> Project: Ignite
> Issue Type: Test
> Reporter: Maksim Davydov
> Assignee: Maksim Davydov
> Priority: Minor
>
> The JMH benchmarks in {{modules/benchmarks}} start the client and server
> nodes in the benchmark JVM. JMH's {{-prof gc}} reports one
> bytes-per-operation number for that whole JVM, so it can't show on which node
> or in which thread pool a change adds allocation. It also undercounts the
> last iteration: the benchmarks stop their nodes in the trial teardown, which
> JMH runs before profilers read the last iteration, so the bytes of the
> stopped nodes are lost.
> This adds:
> * {{JmhAllocationProfiler}}, a JMH profiler ({{-prof}}) that reports bytes
> allocated per operation by the benchmark threads and by each thread pool of
> each node, client or server. It also reports communication messages and bytes
> sent, and discovery messages processed, per operation and node. Threads are
> grouped by the node and pool in their names.
> * {{JmhNodeStopHook}}. {{JmhCacheAbstractBenchmark}} calls it before stopping
> its nodes, so profilers see the last iteration.
> * {{JmhCacheAllocationBenchmark}}: cache put and get on atomic and
> transactional caches, through a client node with two server nodes, run with
> the profiler from its {{main()}}.
> * A README for the module: what the benchmarks measure, how to build and run
> them, how to measure allocation and how to write a benchmark.
> All changes are in {{modules/benchmarks}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
