Author: pmouawad
Date: Thu Jan 4 16:16:03 2018
New Revision: 1820115
URL: http://svn.apache.org/viewvc?rev=1820115&view=rev
Log:
Bug 61931 - Precise Throughput Timer : timer that produces poisson arrivals
with given constant throughput
Contributed by Vladimir Sitnikov
This closes #369
Bugzilla Id: 61931
Added:
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimer.java
- copied, changed from r1819617,
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimer.java
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerBeanInfo.java
- copied, changed from r1819617,
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerBeanInfo.java
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerResources.properties
- copied, changed from r1819617,
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerResources.properties
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerResources_fr.properties
- copied unchanged from r1819617,
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerResources_fr.properties
jmeter/trunk/test/src/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerTest.java
- copied, changed from r1819617,
jmeter/trunk/test/src/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerTest.java
jmeter/trunk/xdocs/images/screenshots/timers/precise_throughput_timer.png
(with props)
Removed:
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimer.java
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerBeanInfo.java
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerResources.properties
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerResources_fr.properties
jmeter/trunk/test/src/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerTest.java
Modified:
jmeter/trunk/xdocs/changes.xml
jmeter/trunk/xdocs/usermanual/component_reference.xml
Copied:
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimer.java
(from r1819617,
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimer.java)
URL:
http://svn.apache.org/viewvc/jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimer.java?p2=jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimer.java&p1=jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimer.java&r1=1819617&r2=1820115&rev=1820115&view=diff
==============================================================================
---
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimer.java
(original)
+++
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimer.java
Thu Jan 4 16:16:03 2018
@@ -36,8 +36,8 @@ import org.slf4j.LoggerFactory;
* On top of that, it tries to maintain the exact amount of arrivals for a
given timeframe ({@link #throughputPeriod}.
* @since 4.0
*/
-public class ExponentialTimer extends AbstractTestElement implements
Cloneable, Timer, TestStateListener, TestBean, ThroughputProvider,
DurationProvider {
- private static final Logger log =
LoggerFactory.getLogger(ExponentialTimer.class);
+public class PreciseThroughputTimer extends AbstractTestElement implements
Cloneable, Timer, TestStateListener, TestBean, ThroughputProvider,
DurationProvider {
+ private static final Logger log =
LoggerFactory.getLogger(PreciseThroughputTimer.class);
private static final long serialVersionUID = 3;
private static final ConcurrentMap<AbstractThreadGroup, EventProducer>
groupEvents = new ConcurrentHashMap<>();
@@ -78,7 +78,7 @@ public class ExponentialTimer extends Ab
@Override
public Object clone() {
- final ExponentialTimer newTimer = (ExponentialTimer) super.clone();
+ final PreciseThroughputTimer newTimer = (PreciseThroughputTimer)
super.clone();
newTimer.testStarted = testStarted; // JMeter cloning does not clone
fields
return newTimer;
}
@@ -132,7 +132,7 @@ public class ExponentialTimer extends Ab
Long seed = randomSeed == null || randomSeed == 0 ? null : randomSeed;
return
groupEvents.computeIfAbsent(tg, x -> new
ConstantPoissonProcessGenerator(
- () -> ExponentialTimer.this.getThroughput() /
throughputPeriod,
+ () -> PreciseThroughputTimer.this.getThroughput() /
throughputPeriod,
batchSize, batchThreadDelay, this, exactLimit,
allowedThroughputSurplus, seed, true));
}
Copied:
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerBeanInfo.java
(from r1819617,
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerBeanInfo.java)
URL:
http://svn.apache.org/viewvc/jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerBeanInfo.java?p2=jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerBeanInfo.java&p1=jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerBeanInfo.java&r1=1819617&r2=1820115&rev=1820115&view=diff
==============================================================================
---
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerBeanInfo.java
(original)
+++
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerBeanInfo.java
Thu Jan 4 16:16:03 2018
@@ -25,9 +25,9 @@ import org.apache.jmeter.testbeans.BeanI
/**
* @since 4.0
*/
-public class ExponentialTimerBeanInfo extends BeanInfoSupport {
- public ExponentialTimerBeanInfo() {
- super(ExponentialTimer.class);
+public class PreciseThroughputTimerBeanInfo extends BeanInfoSupport {
+ public PreciseThroughputTimerBeanInfo() {
+ super(PreciseThroughputTimer.class);
createPropertyGroup(
"delay", //$NON-NLS-1$
new String[]{
Copied:
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerResources.properties
(from r1819617,
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerResources.properties)
URL:
http://svn.apache.org/viewvc/jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerResources.properties?p2=jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerResources.properties&p1=jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerResources.properties&r1=1819617&r2=1820115&rev=1820115&view=diff
==============================================================================
---
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerResources.properties
(original)
+++
jmeter/trunk/src/components/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerResources.properties
Thu Jan 4 16:16:03 2018
@@ -13,7 +13,7 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-displayName=Exponential Timer
+displayName=Precise Throughput Timer
delay.displayName=Delay threads to ensure target throughput
throughput.displayName=Target throughput (in samples per "throughput period")
throughput.shortDescription=Maximum number of samples you want to obtain per
"throughput period", including all threads in group, from all affected samplers
Copied:
jmeter/trunk/test/src/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerTest.java
(from r1819617,
jmeter/trunk/test/src/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerTest.java)
URL:
http://svn.apache.org/viewvc/jmeter/trunk/test/src/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerTest.java?p2=jmeter/trunk/test/src/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerTest.java&p1=jmeter/trunk/test/src/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerTest.java&r1=1819617&r2=1820115&rev=1820115&view=diff
==============================================================================
---
jmeter/trunk/test/src/org/apache/jmeter/timers/poissonarrivals/ExponentialTimerTest.java
(original)
+++
jmeter/trunk/test/src/org/apache/jmeter/timers/poissonarrivals/PreciseThroughputTimerTest.java
Thu Jan 4 16:16:03 2018
@@ -25,8 +25,8 @@ import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-public class ExponentialTimerTest {
- private static final Logger LOG =
LoggerFactory.getLogger(ExponentialTimerTest.class);
+public class PreciseThroughputTimerTest {
+ private static final Logger LOG =
LoggerFactory.getLogger(PreciseThroughputTimerTest.class);
@Test
public void testTimer1() throws Exception {
Modified: jmeter/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=1820115&r1=1820114&r2=1820115&view=diff
==============================================================================
--- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
+++ jmeter/trunk/xdocs/changes.xml [utf-8] Thu Jan 4 16:16:03 2018
@@ -130,7 +130,7 @@ Summary
<h3>Timers, Assertions, Config, Pre- & Post-Processors</h3>
<ul>
<li><bug>60213</bug>New component : Boundary based extractor</li>
- <li><bug>61931</bug>New Component : Exponential Timer, timer that produces
poisson arrivals with given constant throughput </li>
+ <li><bug>61931</bug>New Component : Precise Throughput Timer, timer that
produces poisson arrivals with given constant throughput</li>
<li><bug>61644</bug>HTTP Cache Manager: "Use Cache-Control/Expires header
when processing GET requests" should be checked by default</li>
<li><bug>61645</bug>Response Assertion: Add ability to assert on Request
Data</li>
<li><bug>61534</bug>Convert AssertionError to a failed assertion in the
JSR223Assertion allowing users to use assert in their code</li>
Added: jmeter/trunk/xdocs/images/screenshots/timers/precise_throughput_timer.png
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/images/screenshots/timers/precise_throughput_timer.png?rev=1820115&view=auto
==============================================================================
Binary file - no diff available.
Propchange:
jmeter/trunk/xdocs/images/screenshots/timers/precise_throughput_timer.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Modified: jmeter/trunk/xdocs/usermanual/component_reference.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/component_reference.xml?rev=1820115&r1=1820114&r2=1820115&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/component_reference.xml (original)
+++ jmeter/trunk/xdocs/usermanual/component_reference.xml Thu Jan 4 16:16:03
2018
@@ -5125,7 +5125,120 @@ Note that the throughput value should no
</properties>
</component>
-<component name="Synchronizing Timer" index="§-num;.6.5" width="410"
height="145" screenshot="timers/sync_timer.png">
+<component name="Precise Throughput Timer" index="§-num;.6.5" width="523"
height="318" screenshot="timers/precise_throughput_timer.png">
+<description><p>This timer introduces variable pauses, calculated to keep the
total throughput (e.g. in terms of samples per minute) as close as possible to
a give figure. Of course the throughput will be lower if the server is not
capable of handling it, or if other timers, or if there's not enough threads,
or time-consuming test elements prevent it.</p>
+<p>Although the Timer is called Precise Throughput Timer, it does not aim to
produce precisely the same number of samples over one-second intervals during
the test.</p>
+<p>The timer works best for rates under 36000 requests/hour, however your
milage might vary (see monitoring section below if your goals are
+ vastly different).</p>
+
+<h4>Best location of a Precise Throughput Timer in a Test Plan</h4>
+<p>As you might know, the timers are inherited by all the siblings and their
child elements. That is why one of the best places for
+ <code>Precise Throughput Timer</code> is under the first element in a test
loop. For instance, you might add a dummy sampler at the beginnig,
+ and place the timer under that dummy sampler</p>
+
+<h4>Produced schedule</h4>
+<p><code>Precise Throughput Timer</code> models <a
href="https://en.wikipedia.org/wiki/Poisson_point_process";>poisson arrivals</a>
schedule. That schedule often happens in a real-life, so it makes sense to use
that for load testing.
+ For instance, it naturally might generate samples that are close together
thus it might reveal concurrency issues. Even if you manage to generate poisson
arrivals
+ with <complink name="Poisson Random Timer"/>, it would be suseptible to
the issues listed below. For instance, true poisson arrivals might have
indefinitely long
+ pause, and that is not practical for load testing. For instance, "regular"
poisson arrivals with 1 per second rate might end up with 50 samples over 60
second long test.</p>
+<p><complink name="Constant Throughput Timer"/> converges to the specified
rate, however it tends to produce samples at even intervals.</p>
+
+<h4>Ramp-up and startup spike</h4>
+<p>You might used "ramp-up" or similar approaches to avoid a spike at the test
start. For instance, if you configure <complink name="Thread Group" /> to have
+ 100 threads, and set <code>Ramp-up Period</code> to 0 (or to a small
number), then all the threads would start at the same time, and it would
produce an unwanted spike of the load. On top of that, if you set <code>Ramp-up
Period</code> too high, it might result in "too few" threads being available at
the very beginning to achieve
+the required load.</p>
+<p><code>Precise Throughput Timer</code> schedules executions in a random way,
so it can be used to generate constant load, and it is recommended to set both
+ <code>Ramp-up Period</code> and <code>Delay</code> to <code>0</code>.</p>
+
+<h4>Multiple thread groups starting at the same time</h4>
+<p>A variation of <code>Ramp-up</code> issue might appear when <complink
name="Test Plan" /> includes multiple <complink name="Thead Group" />s. To
mitigate that issue
+ one typically adds "random" delay to each <complink name="Thead Group" />
so threads start at different times.</p>
+<p><code>Precise Throughput Timer</code> avoids that issue since it schedules
executions in a random way. You do not need to add extra random delays to
mitigate startup spike</p>
+
+<h4>Number of iterations per hour</h4>
+<p>One of the basic requirements is to issue N samples per M minutes. Let it
be 60 iterations per hour. Business customers would not understand if you
report load test
+ results with 57 executions "just because the random was random". In order
to generate 60 iterations per hour, you need to configure as follows (other
parameters
+ could be left with their default values)</p>
+<ul>
+ <li><code>Target throughput (samples)</code>: 60</li>
+ <li><code>Throughput period (seconds)</code>: 3600</li>
+ <li><code>Test duration (seconds)</code>: 3600</li>
+</ul>
+<p>The first two options set the throughput. Even though 60/3600, 30/1800, and
120/7200 represent exactly the same load level, pick the one that represents
+ business requirements better. For instance, if the requirement is to test
for "60 sample per hour", then set 60/3600. If the requirement is to test "1
sample per minute",
+ then set 1/60.</p>
+<p><code>Test duration (seconds)</code> is there so the timer ensures exact
number of samples for a given test duration. <code>Precise Throughput
Timer</code> creates
+ a schedule for the samples at the test startup. For instance, if you
+ wish to perform 5 minutes test with 60 per hour throughput, you would set
<code>Test duration (seconds)</code> to 300. This enables to configure
throughput
+ in a business-friendly way. Note: <code>Test duration (seconds)</code>
does <b>not</b> limit test duration. It is just a hint for the timer.</p>
+
+<h4>Number of threads and think times</h4>
+<p>One of the common pitfalls is to adjust number of threads and think times
in order to end up with the desired throughput. Even though it might work, that
approach
+ results in lots of time spent on the test runs. It might require to adjust
threads and delays again when new application version arrives.</p>
+<p><code>Precise Throughput Timer</code> enables to set throughput goal and go
for it no matter how well application performs. In order to do that,
<code>Precise Throughput Timer</code>
+ creates a schedule at the test startup, then it uses that schedule to
release threads. The main driver for the think times and number of threads
should be business
+ requirements, not the desire to match troughput somehow.</p>
+<p>For instance, if you application is used by support engineers in a call
center. Suppose there are 2 engineers in the call center, and the target
throughput is 1 per minute.
+ Suppose it takes 4 minutes for the engineer to read and review the web
page. For that case you should set 2 threads in the group, use 4 minutes
+ for think time delays, and specify 1 per minute in <code>Precise
Throughput Timer</code>. Of course it would result in something around
2samples/4minutes=0.5 per minute
+ and the result of such a test means "you need more support engineers in a
call center" or "you need to reduce the time it takes an engineer to fulfill a
task".</p>
+
+<h4>Testing low rates and repeatable tests</h4>
+<p>Testing at low rates (e.g. 60 per hour) requires to know the desired test
profile. For instance, if you need to inject load at even intervals (e.g. 60
seconds in between)
+ then you'd better use <complink name="Constant Throughput Timer"/>.
However, if you need to have randomized schedule (e.g. to model real users that
execute reports),
+ then <code>Precise Throughput Timer</code> is your friend.</p>
+<p>When comparing outcomes of multiple load tests, it is useful to be able to
repeat exactly the same test profile. For instance, if action X (e.g. "Profit
Report")
+ is invoked after 5 minutes of the test start, then it would be nice to
replicate that pattern for subsequent test executions. Replicating the same
load pattern
+ simplifies analysis of the test results (e.g. CPU% chart).</p>
+<p><code>Random seed (change from 0 to random)</code> enables to control the
seed value that is used by <code>Precise Throughput Timer</code>. By default it
is
+ initialized with <code>0</code> and that means random seed is used for
each test execution. If you need to have repeatable load pattern, then change
+ <code>Random seed</code> so some random value. The general advice is to
use non-zero seed, and "0 by default" is an implementation limit.</p>
+<p>Note: when using multiple thread groups with same throughput rates and same
non-zero seed it might result in unwanted firing the samples at the same
time.</p>
+
+<h4>Testing high rates and/or long test durations</h4>
+<p>When the number of samples is high (e.g. it exceeds 10'000), schedule
generation might take noticeable time (e.g. seconds) as <code>Precise
Throughput Timer</code> tries
+ to produce the exact number of samples. There's memory consumption as
well, however it should not matter much as every item in the schedule consumes
8 bytes.
+ In order to reduce schedule generation overhead, <code>Precise Throughput
Timer</code> allows some slack when generating long schedules. It is controlled
by
+ <code>Accuracy of generated delays</code> properties. By default, inexact
schedules are allowed when number of samples exceeds 10'000.</p>
+<p>If you want to perform 2-week long test with 5'000 per hour rate, you do
not need to create a schedule for that 2 weeks.
+ You can set <code>Test duration (seconds)</code> property of the timer to
1 hour. The timer would create a schedule of 5'000 samples for an hour, and
when the schedule is exhausted, the timer would generate
+ a schedule for the next hour.</p>
+
+<h4>Bursty load</h4>
+<p>There might be a case when all the samples should come in pairs, triples,
etc. Certain cases might be solved via <complink name="Synchronizing Timer"/>,
however
+ <code>Precise Throughput Timer</code> has native way to issue requests in
packs. This behavior is disabled by default, and it is controlled with "Batched
departures"
+ settings</p>
+<ul>
+ <li><code>Number of threads in the batch (threads)</code>. Specifies the
number of samples in a batch. Note the overall number of samples will still be
in line with <code>Target Throughput</code></li>
+ <li><code>Delay between threads in the batch (ms)</code>. For instance, if
set to 42, and the batch size is 3, then threads will depart at x, x+42ms,
x+84ms</li>
+</ul>
+
+<h4>Variable load rate</h4>
+ <p>Even though property values (e.g. throughput) can be defined via
expressions, it is recommended to keep the value more or less the same through
the test, as it takes time to recompute the new schedule to adapt new
values.</p>
+
+<h4>Monitoring</h4>
+<p>As next schedule is generated, <code>Precise Throughput Timer</code> logs a
message to <code>jmeter.log</code>:
+ <code>2018-01-04 17:34:03,635 INFO
o.a.j.t.ConstantPoissonProcessGenerator: Generated 21 timings (... 20 required,
rate 1.0, duration 20, exact lim 20000,
+ i21) in 0 ms, restart was issued 3 times. First 15 events will be fired
at: 1.1869653574244292 (+1.1869653574244292), 1.4691340403043207
(+0.2821686828798915),
+ 3.638151706179226 (+2.169017665874905), 3.836357090410566
(+0.19820538423134026), 4.709330071408575 (+0.8729729809980085),
5.61330076999953 (+0.903970698590955),
+ ...</code>
+This shows that schedule generation took 0ms, and it shows absolute timestamps
in seconds. In the case above, the rate was set to be 1 per second, and the
actual timestamps
+ became 1.2 sec, 1.5 sec, 3.6 sec, 3.8 sec, 4.7 sec, and so on.</p>
+</description>
+<properties>
+ <property name="Name" required="No">Descriptive name for this timer that
is shown in the tree</property>
+ <property name="Target throughput (in samples per 'throughput period')"
required="Yes">Maximum number of samples you want to obtain per "throughput
period", including all threads in group, from all affected samplers.</property>
+ <property name="Throughput period (seconds)" required="Yes">Throughput
period. For example, if "throughput" is set to 42 and "throughput period" to 21
sec, then you'll get 2 samples per second.</property>
+ <property name="Test duration (seconds)" required="Yes">This is used to
ensure you'll get throughput*duration samples during "test duration"
timeframe.</property>
+ <property name="Number of threads in the batch (threads)"
required="Yes">If the value exceeds 1, then multiple threads depart from the
timer simultaneously. Average throughput still meets "throughput"
value.</property>
+ <property name="Delay between threads in the batch (ms)"
required="Yes">For instance, if set to 42, and the batch size is 3, then
threads will depart at x, x+42ms, x+84ms.</property>
+ <property name="Use approximate throughput when sequence length exceeds
(samples)" required="Yes">When the required number of samples is less than this
limit, timer will generate exact number of samples.</property>
+ <property name="Allowed throughput surplus (percents)" required="Yes">When
more than "max exact samples" samples is required, timer might generate
slightly more events than specified by throughput.</property>
+ <property name="Random seed (change from 0 to random)"
required="Yes">Note: different timers should better have different seed values.
Constant seed ensures timer generates the same delays each test start. The
value of "0" means the timer is truly random (non-repeatable from one execution
to another)..</property>
+</properties>
+</component>
+
+<component name="Synchronizing Timer" index="§-num;.6.6" width="410"
height="145" screenshot="timers/sync_timer.png">
<description>
<p>
@@ -5151,7 +5264,7 @@ of its containing Thread group consideri
</component>
-<component name="BeanShell Timer" index="§-num;.6.6" width="846"
height="636" screenshot="timers/beanshell_timer.png">
+<component name="BeanShell Timer" index="§-num;.6.7" width="846"
height="636" screenshot="timers/beanshell_timer.png">
<description>
<p>
The BeanShell Timer can be used to generate a delay.
@@ -5206,7 +5319,7 @@ vars.putObject("OBJ1",new Object());
</component>
-<component name="BSF Timer (DEPRECATED)" index="§-num;.6.7" width="844"
height="636" screenshot="timers/bsf_timer.png">
+<component name="BSF Timer (DEPRECATED)" index="§-num;.6.8" width="844"
height="636" screenshot="timers/bsf_timer.png">
<description>
<p>
The BSF Timer can be used to generate a delay using a BSF scripting language.
@@ -5249,7 +5362,7 @@ vars.putObject("OBJ1",new Object());</so
<p>For details of all the methods available on each of the above variables,
please check the Javadoc</p>
</component>
-<component name="JSR223 Timer" index="§-num;.6.8">
+<component name="JSR223 Timer" index="§-num;.6.9">
<description>
<p>
The JSR223 Timer can be used to generate a delay using a JSR223 scripting
language,
@@ -5294,11 +5407,13 @@ vars.putObject("OBJ1",new Object());</so
<p>For details of all the methods available on each of the above variables,
please check the Javadoc</p>
</component>
-<component name="Poisson Random Timer" index="§-num;.6.9" width="341"
height="182" screenshot="timers/poisson_random_timer.png">
+<component name="Poisson Random Timer" index="§-num;.6.10" width="341"
height="182" screenshot="timers/poisson_random_timer.png">
<description><p>This timer pauses each thread request for a random amount of
time, with most
of the time intervals occurring near a particular value. The total delay is
the
-sum of the Poisson distributed value, and the offset value.</p></description>
+sum of the Poisson distributed value, and the offset value.</p>
+<p>Note: if you want to model poisson arrivals, consider using <complink
name="Precise Throughput Timer"/> instead.</p>
+</description>
<properties>
@@ -5329,17 +5444,6 @@ to the random delay.</property>
</p></description>
-<properties>
- <property name="Name" required="No">Descriptive name for this timer that
is shown in the tree</property>
- <property name="Target throughput (in samples per 'throughput period')"
required="Yes">Maximum number of samples you want to obtain per "throughput
period", including all threads in group, from all affected samplers.</property>
- <property name="Throughput period (seconds)" required="Yes">Throughput
period. For example, if "throughput" is set to 42 and "throughput period" to 21
sec, then you'll get 2 samples per second.</property>
- <property name="Test duration (seconds)" required="Yes">This is used to
ensure you'll get throughput*duration samples during "test duration"
timeframe.</property>
- <property name="Number of threads in the batch (threads)"
required="Yes">If the value exceeds 1, then multiple threads depart from the
timer simultaneously. Average throughput still meets "throughput"
value.</property>
- <property name="Delay between threads in the batch (ms)"
required="Yes">For instance, if set to 42, and the batch size is 3, then
threads will depart at x, x+42ms, x+84ms.</property>
- <property name="Use approximate throughput when sequence length exceeds
(samples)" required="Yes">When the required number of samples is less than this
limit, timer will generate exact number of samples.</property>
- <property name="Allowed throughput surplus (percents)" required="Yes">When
more than "max exact samples" samples is required, timer might generate
slightly more events than specified by throughput.</property>
- <property name="Random seed (change from 0 to random)"
required="Yes">Note: different timers should better have different seed values.
Constant seed ensures timer generates the same delays each test start. The
value of "0" means the timer is truly random (non-repeatable from one execution
to another)..</property>
-</properties>
</component>
