pekko/akka-actor-tests/src/test/scala/akka/util/PrettyDurationSpec.scala

49 lines
1.2 KiB
Scala
Raw Normal View History

=act,tes Initial draft of internal MetricsKit 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 ```
2014-04-29 10:50:36 +02:00
/**
* Copyright (C) 2009-2016 Lightbend Inc. <http://www.lightbend.com>
=act,tes Initial draft of internal MetricsKit 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 ```
2014-04-29 10:50:36 +02:00
*/
package akka.util
=act,tes Initial draft of internal MetricsKit 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 ```
2014-04-29 10:50:36 +02:00
import org.scalatest.FlatSpec
import org.scalatest.Matchers
=act,tes Initial draft of internal MetricsKit 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 ```
2014-04-29 10:50:36 +02:00
class PrettyDurationSpec extends FlatSpec with Matchers {
behavior of "PrettyDuration"
import akka.util.PrettyDuration._
import scala.concurrent.duration._
val cases: Seq[(Duration, String)] =
9.nanos "9.000 ns" ::
95.nanos "95.00 ns" ::
999.nanos "999.0 ns" ::
1000.nanos "1.000 μs" ::
9500.nanos "9.500 μs" ::
9500.micros "9.500 ms" ::
9500.millis "9.500 s" ::
95.seconds "1.583 min" ::
95.minutes "1.583 h" ::
95.hours "3.958 d" ::
=act,tes Initial draft of internal MetricsKit 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 ```
2014-04-29 10:50:36 +02:00
Nil
cases foreach {
case (d, expectedValue)
it should s"print $d nanos as $expectedValue" in {
2015-01-16 11:09:59 +01:00
d.pretty should ===(expectedValue)
=act,tes Initial draft of internal MetricsKit 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 ```
2014-04-29 10:50:36 +02:00
}
}
it should "work with infinity" in {
Duration.Inf.pretty should include("infinity")
}
it should "work with -infinity" in {
Duration.MinusInf.pretty should include("minus infinity")
}
it should "work with undefined" in {
Duration.Undefined.pretty should include("undefined")
}
=act,tes Initial draft of internal MetricsKit 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 ```
2014-04-29 10:50:36 +02:00
}