Re: How would you go about creating a new Thread Group type?

2016-10-17 Thread Deepak Shetty
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  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
>
>   rwils...@gmail.com
>
>
>
>


RE: How would you go about creating a new Thread Group type?

2016-10-17 Thread Robin D. Wilson
The idea with the CSV data set works perfectly. Seems like a good workaround... 
But I'd still like to experiment with building my own Thread Group widget...

--
Robin D. Wilson
Voice: 512-426-3929
rwils...@gmail.com

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Monday, October 17, 2016 4:23 PM
To: JMeter Users List 
Subject: Re: How would you go about creating a new Thread Group type?

On 17 October 2016 at 22:08, Robin D. Wilson  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.
>

You can probably do this by using a CSV Data set with 1 entries.
Each thread picks the next entry (does not matter what it is) and runs the test 
samples.
When all the entries have been used up, stop the test.

But the normal way to do this is to make sure that the test runs for long 
enough that startup and shutdown variations don't affect the results.

>
> 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
>
>   rwils...@gmail.com
>
>
>

-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org



Re: How would you go about creating a new Thread Group type?

2016-10-17 Thread sebb
On 17 October 2016 at 22:08, Robin D. Wilson  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.
>

You can probably do this by using a CSV Data set with 1 entries.
Each thread picks the next entry (does not matter what it is) and runs
the test samples.
When all the entries have been used up, stop the test.

But the normal way to do this is to make sure that the test runs for
long enough that startup and shutdown variations don't affect the
results.

>
> 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
>
>   rwils...@gmail.com
>
>
>

-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org



How would you go about creating a new Thread Group type?

2016-10-17 Thread Robin D. Wilson
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

  rwils...@gmail.com

 



Re: problem with json path extractor

2016-10-17 Thread Philippe Mouawad
Hello,
There are some fixes in nightly build.
Could you try it ?
http://jmeter.apache.org/nightly.html

If issue persists, can you create a demo Test plan using Java Request where
you put the JSON in ResponseData and the JSON-PATH POST PROCESSOR that you
use.

Thank you

On Mon, Oct 17, 2016 at 4:17 PM, Roberto Braga 
wrote:

> I'm having a problem not sure if it is a bug or not.
> Making the long story short.
> I use jmeter 3.0 and bundled json path extractor with some rest api to
> make subsequent calls with foreach.
>
> Lets say we have this scenario
> country api -> region api ->city api->shop list
> Get the country list and extract the array of country id and pass it to a
> foreach get regions list for each country, another call to region api and
> exctract the cities from the result
>
> Generally everithing works, I get an array and the foreach works as
> expected.
> But there are situation where I get only one result, because for instance
> there is only one region in the country.
> In this case json path extractor do not give an array but a simple string
> var. This cause the following foreach to not get executed.
> I'm not sure if this is the normal behaviour but this completely broke my
> script.
> Another strange thinks is that I used the debug sampler to monitor the
> script  and the array never appear there but it exist since the foreach get
> executed, the var appear only when is a string.
>
> Here is a debug example:
>
> idCountryList_1=37
> idCountryList_2=38
> idCountryList_ALL=37,38
> idCountryList_matchNr=2
> idR=8
> idRegioneList_1=8
> idRegioneList_2=12
> idRegioneList_3=3
> idRegioneList_ALL=8,12,3
> idRegioneList_matchNr=3
> idCityList=37006
> idCityList_ALL=37006
> idCityList_matchNr=1
>
>
> for idCountryList I expect to see as first line something like
> idCountryList = [37, 38]
> While idCityList appear because is not an array since the json contain
> just one result.
> In this real example after extracting  the city list I have another api
> call that do not get executed because idCityList is not an array so the
> foreach get jumped.
> I hope I've been clear.
> Thank for any support
> Roberto
>
>
>
>
>
> --
> "Ai sensi e per gli effetti della legge sulla tutela dei dati personali
> (D.lgs 196/2003),
> le informazioni contenute nella presente @mail sono di natura riservata e
> destinate
> ad un uso aziendale-lavorativo con esclusione di utilizzi ad uso
> personale; come tali,
> pertanto, sono riservate esclusivamente ai destinatari sopra indicati. E'
> proibito leggere,
> copiare, usare o diffondere il contenuto della presente @mail senza
> autorizzazione.
> Se avete ricevuto questa @mail per errore, siete pregati di rispedire la
> stessa al mittente.
> Grazie"
>
> -
> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> For additional commands, e-mail: user-h...@jmeter.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.


problem with json path extractor

2016-10-17 Thread Roberto Braga

I'm having a problem not sure if it is a bug or not.
Making the long story short.
I use jmeter 3.0 and bundled json path extractor with some rest api to 
make subsequent calls with foreach.


Lets say we have this scenario
country api -> region api ->city api->shop list
Get the country list and extract the array of country id and pass it to 
a foreach get regions list for each country, another call to region api 
and exctract the cities from the result


Generally everithing works, I get an array and the foreach works as 
expected.
But there are situation where I get only one result, because for 
instance there is only one region in the country.
In this case json path extractor do not give an array but a simple 
string var. This cause the following foreach to not get executed.
I'm not sure if this is the normal behaviour but this completely broke 
my script.
Another strange thinks is that I used the debug sampler to monitor the 
script  and the array never appear there but it exist since the foreach 
get executed, the var appear only when is a string.


Here is a debug example:

idCountryList_1=37
idCountryList_2=38
idCountryList_ALL=37,38
idCountryList_matchNr=2
idR=8
idRegioneList_1=8
idRegioneList_2=12
idRegioneList_3=3
idRegioneList_ALL=8,12,3
idRegioneList_matchNr=3
idCityList=37006
idCityList_ALL=37006
idCityList_matchNr=1


for idCountryList I expect to see as first line something like
idCountryList = [37, 38]
While idCityList appear because is not an array since the json contain 
just one result.
In this real example after extracting  the city list I have another api 
call that do not get executed because idCityList is not an array so the 
foreach get jumped.

I hope I've been clear.
Thank for any support
Roberto





--
"Ai sensi e per gli effetti della legge sulla tutela dei dati personali 
(D.lgs 196/2003),
le informazioni contenute nella presente @mail sono di natura riservata e 
destinate
ad un uso aziendale-lavorativo con esclusione di utilizzi ad uso personale; 
come tali,
pertanto, sono riservate esclusivamente ai destinatari sopra indicati. E' 
proibito leggere,
copiare, usare o diffondere il contenuto della presente @mail senza 
autorizzazione.
Se avete ricevuto questa @mail per errore, siete pregati di rispedire la 
stessa al mittente.

Grazie"

-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org