Class Workload
WorkloadReport report = Workload.named("orders-peak")
.topology(t -> t
.exchange("orders", "topic")
.queue("orders.new")
.boundTo("orders", "order.created"))
.publishers(p -> p
.threads(4)
.rate(50_000)
.messageSize(1024))
.consumers(c -> c
.concurrency(8)
.prefetch(100)
.handlerTime(Duration.ofMillis(1)))
.warmup(Duration.ofSeconds(10))
.runFor(Duration.ofMinutes(2))
.expect(Objective.throughputAtLeast(45_000))
.expect(Objective.p99Below(Duration.ofMillis(50)))
.run("amqp://localhost");
System.out.println(report.format());
Three things kept apart
Topology is what the messages travel through. Publishers and consumers are the shape of the load. Objectives are what the result has to satisfy. They change independently — the same topology under ten load profiles, or the same load against a classic queue and a quorum queue — and a DSL that chained them together would force all three to be rewritten to vary one.
Warm-up is not measured
Workload.Builder.warmup(Duration) runs the workload and throws the measurements away. The first
seconds of any JVM workload measure class loading, JIT compilation, connection and channel
setup and the first garbage collection, none of which the broker is responsible for. Without a
warm-up those costs land in the p99 and stay there.
-
Nested Class Summary
Nested Classes -
Method Summary
Modifier and TypeMethodDescriptionduration()name()static Workload.Builderrules()Runs it.Runs it against a broker that needs more than a URL to reach.booleanstart(String brokerUrl, org.acemq.amqp.security.Security security, RunListener listener) Starts it against a broker that needs more than a URL to reach.start(String brokerUrl, RunListener listener) Starts it on a thread of its own, and reports as it goes.topology()toString()warmup()
-
Method Details
-
named
- Parameters:
name- what to call this workload, in the report- Returns:
- a builder
-
name
-
topology
-
publishers
-
consumers
-
warmup
-
duration
-
runsUntilStopped
public boolean runsUntilStopped()- Returns:
- true when this run ends only on being stopped, rather than after a set window
-
rules
-
run
Runs it.- Parameters:
brokerUrl- an AMQP URL, for exampleamqp://guest:guest@localhost:5672- Returns:
- what happened
-
run
Runs it against a broker that needs more than a URL to reach.- Parameters:
brokerUrl- an AMQP URL, for exampleamqps://guest:guest@localhost:5671security- which certificates to believe, or null to let the URL decide — plaintext foramqp://and the JVM's own trust store foramqps://- Returns:
- what happened
-
start
Starts it on a thread of its own, and reports as it goes.For anything that cannot block for the length of a run: a user interface drawing it live, a scheduler, a test that stops the run once it has seen enough.
RunHandle run = workload.start("amqp://localhost", System.out::println); // ... and later run.stop(); WorkloadReport report = run.report().join();- Parameters:
brokerUrl- an AMQP URLlistener- told about each reading, orRunListener.NONE- Returns:
- a handle on the run
-
start
public RunHandle start(String brokerUrl, org.acemq.amqp.security.Security security, RunListener listener) Starts it against a broker that needs more than a URL to reach.- Parameters:
brokerUrl- an AMQP URLsecurity- which certificates to believe, or null to let the URL decidelistener- told about each reading, orRunListener.NONE- Returns:
- a handle on the run
-
toString
-