Note: This is NOT aimed to provide an micro-benchmarking solution.
The goal is to provide data for broad trend analysis. For techniques
that fight the inliner and other specialised techniques, refer to JMH.
+ custom console and graphite reporters
- had to be custom because it's not possible to add custom metric
types to the existing reporters
+ initial hdr.Histogram histogram() provider, see
http://latencyutils.github.io/LatencyUtils/
+ Not using timers provided by Metrics, instead use the above histogram
+ Added average Actor size measurement
+ Measuring the "blocking time" when an actor is created, before we fire
of the async part of this process; Measures in loop and will fluctuate
a lot. Times are in `us` -- System.nanoTime should provide good enough
resolution.
+ Measuring total actor creation time by using
`KnownOpsInTimespanTimer`, which given a known number of ops, in a
large amount of time, roughtly estimates time per one operation.
// Yes, we are aware of the possibility of GC pauses and other horrors
+ All classes are `private[akka]`, we should not encourage people to use
this yet
+ Counters use Java 8's `LongAdder`, which is metric's private;
The new trend in Java land will be copy paste-ing this class ;)
+ Metrics are logged to Graphite, so we can long-term analyse these
+ Reporters are configurable using typesafe-config
! I'm not very happy about how I work around Metrics not being too open
for adding additional custom metrics. Seems like a hack at places.
I will consider removing the Metrics dependency all together.
numbers
Example output:
```
-- KnownOpsInTimespanTimer-------------------------------------------
actor-creation.total.creating-100000-actors.Props|new-EmptyArgsActor|…||-same
ops = 100000
time = 1.969 s
ops/s = 50782.22
avg = 19.69 μs
-- AveragingGauge---------------------------------------------------
actor-creation.Props|new-EmptyArgsActor|…||-same.avg-mem-per-actor
avg = 439.67
```
- it’s a completely new-written thing in pure Java, so that “protected”
modifiers actually work and no ghost errors appear wrt. inheriting
from PartialFunction or similar
- it also features integration with the EventFilter
- all closure-based constructs are modeled as inner classes of the
JavaTestKit, where the user needs to override a single method which
will then be executed
