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 06:46:25 GMT
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
>
>
>
>

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