Maksim Davydov created IGNITE-29147:
---------------------------------------
Summary: Add an allocation profiler that splits bytes per
operation by node and thread pool
Key: IGNITE-29147
URL: https://issues.apache.org/jira/browse/IGNITE-29147
Project: Ignite
Issue Type: Test
Reporter: Maksim Davydov
Assignee: Maksim Davydov
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}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
