You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jmeter.apache.org by pm...@apache.org on 2018/01/04 16:16:04 UTC
svn commit: r1820115 - in /jmeter/trunk:
src/components/org/apache/jmeter/timers/poissonarrivals/
test/src/org/apache/jmeter/timers/poissonarrivals/ xdocs/
xdocs/images/screenshots/timers/ xdocs/usermanual/
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>