jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Goel <deic...@gmail.com>
Subject RE: How would you go about creating a new Thread Group type?
Date Fri, 21 Oct 2016 14:09:02 GMT
your assumption that the slowest thread takes 20sec and the fastest thread
takes 10 sec is false. Usually the difference is in milliseconds and over a
period of time,  it becomes zero. All threads receive their answer in about
the same time..they have to wait or queue for the same time

On Oct 21, 2016 6:31 PM, "Robin D. Wilson" <rwilson2@gmail.com> wrote:

> If you have a thread group with 10 HTTP Request samplers in it (or 100, or
> 1000, whatever the number is - the more you have, the more pronounced this
> concern will become), and you run a thread that steps through each of the
> samplers in sequence, some threads will get done sooner than others - that
> is practically guaranteed - since there is no way that the server will
> respond identically quickly to each request.
>
> So, after 1 loop through your test plan you will have a bell curve of
> times it took for each thread to complete the loop. A few threads will have
> completed relatively fast, a few will have completed relatively slower, and
> the bulk of the threads will have completed with times somewhere in the
> middle. Let's say that the fastest thread completes the full set of
> requests for the loop in 10 seconds. And the slowest thread completes the
> loop in 20 seconds. For argument's sake, let's say that the differential
> between fastest and slowest is not necessarily due to the capacity of the
> server, but just an artifact of random chance - the fastest thread caught
> all the green lights, and the slowest thread caught all the red lights
> (e.g., i/o blocking, lock waits, network congestion back offs, etc.)...
>
> If you re-start the loop for each thread, as soon as it completes the last
> loop - then the fast threads will restart much earlier than the loops that
> are completing on the slower end of the curve. In fact, given that the
> 'fastest' time was only 10 seconds, and the slowest time was 20 seconds -
> there is a non-zero chance that the fastest thread could actually complete
> another full loop by the time the slowest thread is completing its first
> full loop.
>
> If you assign the loops based on a pure division of "number of loops /
> number of threads", you will assure that each thread has an equal number of
> loops. But you will also assure that some threads complete their total
> number of loops well before other threads complete their full set of loops.
> Moreover, the longer your test run is, the wider the disparity will be
> between the threads that reach their full loop count early, and the threads
> that finish the full loop count last. Such that, the slower running threads
> may be running their last several loops while the faster threads have
> completely died off - meaning that the last few threads will be running
> while the machine is under a progressively lighter load.
>
> Clearly, you can't help this from happening during the 'last' loop for
> every thread, since each thread must stop once it has completed a full loop
> - if there are no more loops left to run. But if you don't really care how
> many times each thread runs a loop, you could schedule the loops from a
> queue - where instead of pre-calculating the total loops for each thread,
> you just maintained the total number of loops you needed for the test to
> run, and each thread would just decrement the count when it finished its
> previous loop. Once the count drops all the way to '0', all of the threads
> still running would complete their final loops, and the test would be done.
> BUT no threads would be starting new loops while the server was under a
> lighter load (even though they would complete their last loops while the
> load steadily declined).
>
> Sebb's suggestion of just using a CSV file to count the loops accomplishes
> this exact requirement. If I want a test to run 100,000 loops, I just
> supply a CSV file with 100000 records it. Then I set the Thread Group to
> run "Infinite" loops, and set the CSV file to stop on EOF. The test runs
> until the 100000th record is retrieved from the CSV file, and once that
> loop starts - the threads all stop when they finish their most recent loop
> because they can't get another record from the CSV. (HINT: you can give the
> CSV variable a name like 'loop_count', and make your CSV file contain
> records that count up from 1-100000, and you will also gain a variable that
> tells you which loop you were on for specific sets of requests.)
>
> This isn't a huge concern, just a way to make sure that you maintain the
> same relative server load all through the duration of the test.
>
> --
> Robin D. Wilson
> Voice: 512-426-3929
> rwilson2@gmail.com
>
> -----Original Message-----
> From: Deepak Goel [mailto:deicool@gmail.com]
> Sent: Friday, October 21, 2016 1:46 AM
> To: JMeter Users List <user@jmeter.apache.org>
> Subject: Re: How would you go about creating a new Thread Group type?
>
> I am not sure I understand your problem correctly...
>
> Why would the load be reduced to 99 threads? As the threads which haven't
> finished their earlier cycle are still running...they are spending time
> finishing their previous request (which would also indicate a problem with
> the server responding the request)
>
> Hey
>
> Namaskara~Nalama~Guten Tag~Bonjour
>
>
>    --
> Keigu
>
> Deepak
> 73500 12833
> www.simtree.net, deepak@simtree.net
> deicool@gmail.com
>
> LinkedIn: www.linkedin.com/in/deicool
> Skype: thumsupdeicool
> Google talk: deicool
> Blog: http://loveandfearless.wordpress.com
> Facebook: http://www.facebook.com/deicool
>
> "Contribute to the world, environment and more :
> http://www.gridrepublic.org "
>
> On Tue, Oct 18, 2016 at 2:38 AM, Robin D. Wilson <rwilson2@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:rwilson2@gmail.com> rwilson2@gmail.com
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message