On 18 May 2015 at 20:47, Vladimir Sitnikov <[email protected]> wrote: > I would rather approach it from "best practices" point of view. > Even though experienced users might want different kind of workloads, > I think it makes sense including basic best practices right into the > documentation. > > Well, it would be good if JMeter documentation would suggest "the best > approach for the test in question". > I think it is perfectly reasonable to reference "external plugins" > right in "jmeter core" documentation. > The message is as follows: we see you might need that case, however we > did not include it in core because bla-bla-bla, so you can just grab > that plugin and that will cover your case.
We cannot favour one 3rd party plugin over another, however we can reiterate that JMeter is open source and plugabble and that there are external plugins for it. > How would users find proper plugin if JMeter's site never mentions > "good and battle-tested" plugins? We don't test and cannot recommend particular 3rd party plugins. > For instance, there are two main kinds of load: > 1) "X requests per second". This is somewhat covered by > http://jmeter-plugins.org/wiki/ThroughputShapingTimer/. > "in-core throughput shaping timer" does not have "good gui to define > stepping/increasing load". > > Both in-core and jmeter-plugins timers canNOT issue "poisson arrival process". > Here's the description why that is important: > http://perfdynamics.blogspot.ru/2012/05/load-testing-with-uniform-vs.html > > 2) "X concurrent threads working non-stop". > Frankly speaking, I never use that kind of tests, however I might > agree they might serve their purpose. > This is covered by Ultimate Thread Group. > > Vladimir
