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. How would users find proper plugin if JMeter's site never mentions "good and battle-tested" 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
