Jmeter-plugins probably has source that you could use to see how they
implemented the various other thread groups (.e.g
https://jmeter-plugins.org/wiki/UltimateThreadGroup/)

On Mon, Oct 17, 2016 at 2:08 PM, Robin D. Wilson <rwils...@gmail.com> wrote:

> Just throwing this out there - to see if anyone wants to lead a code-level
> newbie down the right path. I've been using JMeter for
> 8-9 years now, and really like it. But one thing that bugs me is the way
> the Thread Group works. Specifically, the idea of the
> "loops" bothers me.
>
>
>
> Consider this scenario:
>
>
>
> 1)     100 "users" (e.g., threads)
>
> 2)     10 loops
>
> 3)     Test has 10 HTTP Requests in it
>
>
>
> By this logic, you should end up with 100 (users) X 10 loops X 10 HTTP
> Requests = 10,000 requests.
>
>
>
> And you do.
>
>
>
> BUT, what you actually get when you run the test isn't as clear as you
> think. It is basically 100 threads, each running 10 times,
> and each thread loop running 10 HTTP requests in sequence.
>
>
>
> Here's the problem, if thread 1 completes its 10 loops in 100 seconds, but
> threads 2-100 take 200 seconds to complete their 10
> loops. The load will be reduced to only 99 simultaneous threads (users)
> for the last 100 seconds of the test run. That's not a
> 'huge' deal, but it can affect the perception of the test if you look at
> it more like threads 1-50 finish in 100 seconds, and
> threads 51-100 take an extra 100 seconds after that to complete. Then only
> half of your test cycle was at the required 'max' load
> you wanted to create, while the other half was at 50% of the required
> load. (It is reasonably possible that I'm just misinterpreting
> how it actually works, but it appears to work like this from my experience
> since I can see threads continuing to process after some
> threads appear to stop - and it lasts longer than it takes to get through
> the entire cycle - sometimes for several minutes at the
> end of a test run.)
>
>
>
> I'd like to create a new Thread Group that doesn't assign the thread to
> the loop until it starts again at the top of the cycle. So
> if thread-1 finishes really fast, and there are still loops to run - it
> just picks up another loop and runs it. I would always want
> to maintain at least 100 threads executing, so long as there were loops
> left to run. So basically, you multiply the number of loops
> by the number of threads (1000 in my example), and your 100 threads always
> restart until there are no loops left to run. Then the
> longest period you have where you aren't fully loading the servers is just
> the last loop for every thread.
>
>
>
> BUT, I am not 100% sure where I would start in the source code. I have
> programmed before (a long time ago), but if someone could
> point me in the right direction (like, which source files would need to be
> modified, and how would I register my new Thread Group as
> a different option), I think I could figure it out pretty quickly.
>
>
>
> --
>
> Robin D. Wilson
>
>  <mailto:rwils...@gmail.com> rwils...@gmail.com
>
>
>
>

Reply via email to