[
https://issues.apache.org/jira/browse/AMQ-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077910#comment-14077910
]
Jakub Korab commented on AMQ-5294:
----------------------------------
Have made the necessary changes and will send a pull request. The logic that
has been implemented attempts to make the configuration as minimal and sane as
possible without breaking existing workflows.
The logic works by deferring the sampler behaviour to client
(producer/consumer) settings by default.
If the client asks to send/receive messages by count, both the duration of the
samplers and the ramp up/down times are ignored; this is due to the
non-deterministic nature of the completion time.
If the client asks send/receive messages by time, the default behaviour for a
sampler is:
* use the client duration as its duration, unless explicitly overridden (e.g.
tpSampler.duration=15000) - then it's the user's call
* set the ramp up time to 0, and the ramp down time to 0
A user may override the default behaviour by either:
* setting the rampUpTime/rampDownTime - this is the highest level override
* setting two new properties rampUpPercent/rampDownPercent. These properties
cannot exceed 100 in total, and boundary checks are in place.
> Unify client and sampler timings in activemq-perf-maven-plugin
> --------------------------------------------------------------
>
> Key: AMQ-5294
> URL: https://issues.apache.org/jira/browse/AMQ-5294
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Performance Test
> Affects Versions: 5.10.0
> Environment: All
> Reporter: Jakub Korab
> Priority: Minor
>
> Fundamentally there are 2 entities in the plugin managed by different
> threads/threadpools:
> * the client (generic term for producer of consumer)
> * the samplers (throughput + cpu)
> These entities can all be configured separately, and the plugin does not
> complete until the slowest of these is done. Now, the problem is that
> these things all have separate flags, which generally aren't overridden
> unless you want to use a really long command line. For example, to get a
> perf test that runs for 10 seconds, you have to do the following:
> mvn activemq-perf:producer -Dproducer.sendDuration=10000
> -DtpSampler.duration=10000 -DtpSampler.rampUpTime=0
> -DtpSampler.rampDownTime=0 -DcpuSampler.duration=10000
> -DcpuSampler.rampUpTime=0 -DcpuSampler.rampDownTime=0
> And all this is before you start adding flags to do anything useful with
> it. This is because:
> 1. sampler threads sleep for the ramp-up time (default 30s); if this
> is longer than the producer's send duration then the sampler won't
> even start doing anything until |the producer has well and truly
> completed
> 2. the test runs until the longest configured sampler (by default both
> throughput + cpu run)
> So it's kind of a mess. I'd love to be able to use the principle of
> least surprise (and configuration) so that you can just do this:
> mvn activemq-perf:producer -Dproducer.sendDuration=10000
> mvn activemq-perf:producer -Dproducer.sendType=count
> -Dproducer.sendCount=10000
--
This message was sent by Atlassian JIRA
(v6.2#6252)
