Re: Error in Test Plan: See Log file.
I also get this message from time to time. I have no idea what causes it (more knowledgable users may be able to help with this), but in my experience, it is more likely to occur the larger the file becomes. My Test Plan has around 5000 different samplers (it is used for functional regression testing) and it happened a lot when I was in the final stages of building it. The log file should show you the line that is corrupted... and in my experience it's usually a problem with a tag not being closed. Diagnosing this is a lot of work though, so to get around this issue I created a local svn and save. So, always save lots. Save some more. This minimises the amount of work you lose should you get this problem, but also tends to stop this issue from occuring at all. Again, other users might have some insight... this is just my work around, learnt through tears of pain and frustration at losing days worth of work because I haven't saved regularly. Please learn from my experience :) -- View this message in context: http://jmeter.512774.n5.nabble.com/Error-in-Test-Plan-See-Log-file-tp5691698p5713490.html Sent from the JMeter - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: TCP Sampler Read Exception
On 12 June 2012 09:56, Shay Ginsbourg sginsbo...@gmail.com wrote: Hi all, Can anyone suggest what does the following error mean ? After each TCP sampler, we receive Response code: 500 and Response message: org.apache.jmeter.protocol.tcp.sampler.ReadException: Any help would be greatly appreciated. Most likely the read terminated unexpectedly: http://jmeter.apache.org/api/org/apache/jmeter/protocol/tcp/sampler/TCPClient.html#read%28java.io.InputStream%29 thanks, Shay - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Updatiung CSV Parameters in Each reauest in Iteration
Hi There, I have a thread group with several requests in it. All request have the same parameter in them. I also have a csv file with values for that parameter. How can I link my jmeter project to the csv file, so that each request sends a new value from the file? I tried the csv dataset config(by putting under each request), but that one seems to send the same parameter value with all requests per thread iteration. This is not enough. I need a fresh value read from the csv file with every single request. How can I accomplish this? Is it possibel, to make jmeter pick a random line from that csv file? Regards, thanks in advance.
Re: Updatiung CSV Parameters in Each reauest in Iteration
Add CSV Data Set Config below thread group. Provide the CSV file
name\path (if not placed in Bin folder) in filename.
Now for ex if you want new user name for each iteration, then add Users in
CSV. Add variable names in CSV Data Set Config element say Username.
Then in all your requests replace user name with ${Username}. You are good
to go.
On Tue, Jun 12, 2012 at 5:57 PM, hans jung junghansm...@googlemail.comwrote:
Hi There,
I have a thread group with several requests in it. All request have the
same parameter in them.
I also have a csv file with values for that parameter.
How can I link my jmeter project to the csv file, so that each request
sends a new value from the file?
I tried the csv dataset config(by putting under each request), but that one
seems to send the same parameter value with all requests per thread
iteration.
This is not enough. I need a fresh value read from the csv file with every
single request.
How can I accomplish this?
Is it possibel, to make jmeter pick a random line from that csv file?
Regards, thanks in advance.
Re: Updatiung CSV Parameters in Each reauest in Iteration
Ok, but I have several requests.
Each Request uses the parameter ${username}.
What I see s that all requests use the exact same username
I want each request to pick a new username.
How can I do this in jmeter?
2012/6/12 Niraj niraj.khatm...@gmail.com
Add CSV Data Set Config below thread group. Provide the CSV file
name\path (if not placed in Bin folder) in filename.
Now for ex if you want new user name for each iteration, then add Users in
CSV. Add variable names in CSV Data Set Config element say Username.
Then in all your requests replace user name with ${Username}. You are good
to go.
On Tue, Jun 12, 2012 at 5:57 PM, hans jung junghansm...@googlemail.com
wrote:
Hi There,
I have a thread group with several requests in it. All request have the
same parameter in them.
I also have a csv file with values for that parameter.
How can I link my jmeter project to the csv file, so that each request
sends a new value from the file?
I tried the csv dataset config(by putting under each request), but that
one
seems to send the same parameter value with all requests per thread
iteration.
This is not enough. I need a fresh value read from the csv file with
every
single request.
How can I accomplish this?
Is it possibel, to make jmeter pick a random line from that csv file?
Regards, thanks in advance.
JMeter threading model
Hi, I guess this is mostly directed towards Sebb.. I spent a bit looking at JMeter performance today. What I found was that the thread group starts all of it's threads at the beginning and then uses them over time. Is there a way to easily change this so that the thread group only creates threads on demand? Regards, Kirk - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: TCP Sampler Read Exception
Feel free to copy and paste here the complete error. Shmuel. On Tue, Jun 12, 2012 at 12:02 PM, sebb seb...@gmail.com wrote: On 12 June 2012 09:56, Shay Ginsbourg sginsbo...@gmail.com wrote: Hi all, Can anyone suggest what does the following error mean ? After each TCP sampler, we receive Response code: 500 and Response message: org.apache.jmeter.protocol.tcp.sampler.ReadException: Any help would be greatly appreciated. Most likely the read terminated unexpectedly: http://jmeter.apache.org/api/org/apache/jmeter/protocol/tcp/sampler/TCPClient.html#read%28java.io.InputStream%29 thanks, Shay - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Updatiung CSV Parameters in Each reauest in Iteration
Put the CSV Data Set Config under the thread group and do not duplicate it
under each sampler.
This way all samplers will share the same dataset.
Shmuel.
On Tue, Jun 12, 2012 at 6:19 PM, hans jung junghansm...@googlemail.comwrote:
Ok, but I have several requests.
Each Request uses the parameter ${username}.
What I see s that all requests use the exact same username
I want each request to pick a new username.
How can I do this in jmeter?
2012/6/12 Niraj niraj.khatm...@gmail.com
Add CSV Data Set Config below thread group. Provide the CSV file
name\path (if not placed in Bin folder) in filename.
Now for ex if you want new user name for each iteration, then add Users
in
CSV. Add variable names in CSV Data Set Config element say Username.
Then in all your requests replace user name with ${Username}. You are
good
to go.
On Tue, Jun 12, 2012 at 5:57 PM, hans jung junghansm...@googlemail.com
wrote:
Hi There,
I have a thread group with several requests in it. All request have the
same parameter in them.
I also have a csv file with values for that parameter.
How can I link my jmeter project to the csv file, so that each request
sends a new value from the file?
I tried the csv dataset config(by putting under each request), but that
one
seems to send the same parameter value with all requests per thread
iteration.
This is not enough. I need a fresh value read from the csv file with
every
single request.
How can I accomplish this?
Is it possibel, to make jmeter pick a random line from that csv file?
Regards, thanks in advance.
Re: JMeter threading model
Hi, I figured thread pooling would be revolutionary so I wasn't suggesting that. I would be very useful just delay the creation of a thread until it was asked for. Regards, Kirk On 2012-06-12, at 8:46 PM, Philippe Mouawad wrote: Hello M. Pepperdine, There is no way today to do that. There is an enhancement request that has not been implemented yet although started some time ago: - https://issues.apache.org/bugzilla/show_bug.cgi?id=47886 JMeter core is build around the paradigm: - 1 user == 1 Thread - And lot of its internal behaviour makes this supposition This could be changed in 2 ways: - 1) use for example a ThreadPoolExecutor without limiting its growth to avoid thread starvation during a Load Test but to create as little threads as possible - 2) Use a completely different approach based on something like netty but this one would be a revolution and a too big impact in my opinion But even with 1) we have to handle the ThreadLocal objects currently used so this need through investigation. Regards Philippe M. http://www.ubik-ingenierie.com On Tue, Jun 12, 2012 at 6:28 PM, Shmuel Krakower shmul...@gmail.com wrote: Hi, I was thinking to suggest working with JP@GC Ultimate thread group, but it behaves the same (pre-creating the threads). Kirk, why does it matter to you? Regards, Shmuel. On Tue, Jun 12, 2012 at 6:31 PM, Kirk Pepperdine kirk.pepperd...@gmail.comwrote: Hi, I guess this is mostly directed towards Sebb.. I spent a bit looking at JMeter performance today. What I found was that the thread group starts all of it's threads at the beginning and then uses them over time. Is there a way to easily change this so that the thread group only creates threads on demand? Regards, Kirk - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Cordialement. Philippe Mouawad. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: JMeter threading model
On 12 June 2012 22:06, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: Hi, I figured thread pooling would be revolutionary so I wasn't suggesting that. I would be very useful just delay the creation of a thread until it was asked for. Not sure I understand how it would help to delay the thread creation, except perhaps for the case where the first threads have finished processing by the time the last threads start running samples. Regards, Kirk On 2012-06-12, at 8:46 PM, Philippe Mouawad wrote: Hello M. Pepperdine, There is no way today to do that. There is an enhancement request that has not been implemented yet although started some time ago: - https://issues.apache.org/bugzilla/show_bug.cgi?id=47886 JMeter core is build around the paradigm: - 1 user == 1 Thread - And lot of its internal behaviour makes this supposition This could be changed in 2 ways: - 1) use for example a ThreadPoolExecutor without limiting its growth to avoid thread starvation during a Load Test but to create as little threads as possible - 2) Use a completely different approach based on something like netty but this one would be a revolution and a too big impact in my opinion But even with 1) we have to handle the ThreadLocal objects currently used so this need through investigation. Regards Philippe M. http://www.ubik-ingenierie.com On Tue, Jun 12, 2012 at 6:28 PM, Shmuel Krakower shmul...@gmail.com wrote: Hi, I was thinking to suggest working with JP@GC Ultimate thread group, but it behaves the same (pre-creating the threads). Kirk, why does it matter to you? Regards, Shmuel. On Tue, Jun 12, 2012 at 6:31 PM, Kirk Pepperdine kirk.pepperd...@gmail.comwrote: Hi, I guess this is mostly directed towards Sebb.. I spent a bit looking at JMeter performance today. What I found was that the thread group starts all of it's threads at the beginning and then uses them over time. Is there a way to easily change this so that the thread group only creates threads on demand? Regards, Kirk - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Cordialement. Philippe Mouawad. - 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: JMeter threading model
On 12 June 2012 22:57, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: On 2012-06-13, at 12:54 AM, sebb wrote: On 12 June 2012 22:06, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: Hi, I figured thread pooling would be revolutionary so I wasn't suggesting that. I would be very useful just delay the creation of a thread until it was asked for. Not sure I understand how it would help to delay the thread creation, except perhaps for the case where the first threads have finished processing by the time the last threads start running samples. Bingo!!! ;-) So what percentage of use cases need to follow this model? Most of the JMeter testing I have done was long running tests where all threads were active for most of the run. Kirk - 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: JMeter threading model
Currently, JMeter will run 100 threads, for 100 iterations each in order to reach 10,000 total passes through my test case. If thread 1 completes its 100 iterations before any of the rest of the threads, it terminates and then I only have 99 threads running until the 10,000 iterations complete. My test will show a performance change at the end - as the number of total simultaneous threads begins to trail off, the performance will appear to improve. For example, I will show the sampler as having completed 9200 requests when the first thread finishes its 100 iterations. This means for the remaining 800 requests, I only have a maximum 99 threads operating. Then at 9300 samples, 19 more threads might have died off - so I only have 80 threads max operating for the remaining 700 requests. As you can imagine, this means that by the end of the test - the performance numbers will start to progressively improve (since fewer threads means less workload on the process being measured, and therefore faster response times). It would be really nice if JMeter just kept a pool of 100 threads operating on requests for the duration of the 10,000 iterations, so that threads would only die off during the final iteration, leaving the server at more-or-less peak load throughout the test. From a code standpoint, this doesn't seem like it would be too hard to setup - just identify how many total iterations need to be run through the thread group, startup the total number of threads you need, and let each thread keep going until all the iterations have been started. (Of course, I say that knowing that I'm just a 'manager' type, and won't be coding it myself...) -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, June 12, 2012 5:02 PM To: JMeter Users List Subject: Re: JMeter threading model On 12 June 2012 22:57, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: On 2012-06-13, at 12:54 AM, sebb wrote: On 12 June 2012 22:06, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: Hi, I figured thread pooling would be revolutionary so I wasn't suggesting that. I would be very useful just delay the creation of a thread until it was asked for. Not sure I understand how it would help to delay the thread creation, except perhaps for the case where the first threads have finished processing by the time the last threads start running samples. Bingo!!! ;-) So what percentage of use cases need to follow this model? Most of the JMeter testing I have done was long running tests where all threads were active for most of the run. Kirk - 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 - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: JMeter threading model
On 12 June 2012 23:42, Robin D. Wilson rwils...@gmail.com wrote: Currently, JMeter will run 100 threads, for 100 iterations each in order to reach 10,000 total passes through my test case. If thread 1 completes its 100 iterations before any of the rest of the threads, it terminates and then I only have 99 threads running until the 10,000 iterations complete. My test will show a performance change at the end - as the number of total simultaneous threads begins to trail off, the performance will appear to improve. For example, I will show the sampler as having completed 9200 requests when the first thread finishes its 100 iterations. This means for the remaining 800 requests, I only have a maximum 99 threads operating. Then at 9300 samples, 19 more threads might have died off - so I only have 80 threads max operating for the remaining 700 requests. As you can imagine, this means that by the end of the test - the performance numbers will start to progressively improve (since fewer threads means less workload on the process being measured, and therefore faster response times). It would be really nice if JMeter just kept a pool of 100 threads operating on requests for the duration of the 10,000 iterations, so that threads would only die off during the final iteration, leaving the server at more-or-less peak load throughout the test. JMeter can do this already. Rather than specify a fixed number of loops, use a CSV Config file with 10,000 entries, and set it to stop the thread (not the test, as that would not let some threads complete) when EOF is reached. For tests where a CSV data file is not appropriate or convenient, it might make sense to implement a feature which counts total loops and causes the test to stop when a pre-specified limit is reached. Perhaps at thread group level, which already has a duration limit. Or a test element of some kind. From a code standpoint, this doesn't seem like it would be too hard to setup - just identify how many total iterations need to be run through the thread group, startup the total number of threads you need, and let each thread keep going until all the iterations have been started. (Of course, I say that knowing that I'm just a 'manager' type, and won't be coding it myself...) -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, June 12, 2012 5:02 PM To: JMeter Users List Subject: Re: JMeter threading model On 12 June 2012 22:57, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: On 2012-06-13, at 12:54 AM, sebb wrote: On 12 June 2012 22:06, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: Hi, I figured thread pooling would be revolutionary so I wasn't suggesting that. I would be very useful just delay the creation of a thread until it was asked for. Not sure I understand how it would help to delay the thread creation, except perhaps for the case where the first threads have finished processing by the time the last threads start running samples. Bingo!!! ;-) So what percentage of use cases need to follow this model? Most of the JMeter testing I have done was long running tests where all threads were active for most of the run. Kirk - 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 - 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: JMeter threading model
sorry i think i misread your email. But it would make my test a better measure of operating characteristics of my system 'under load' to have it consistently maintain the full number of requesting threads throughout the test. Cant you already do this? fix the duration of the test instead of the number of times you want to run . still seems unrelated to kirk's request :) On Tue, Jun 12, 2012 at 4:01 PM, Robin D. Wilson rwils...@gmail.com wrote: I'm not sure I follow... My JMeter test runs on a single Win7 box. My test environment consists of a web server, multiple Java App servers and a database server. The performance appears to improve because I'm hitting the test environment with fewer and fewer threads as the test begins to wrap up. I'm just saying that it would be nice if I could delay that drop-off until I get to the last 100 samples, rather than several hundred samples before the test ends. It probably doesn't make a big difference to me - since I'm really just comparing the results of the last time I ran the test against the results of this time. But it would make my test a better measure of operating characteristics of my system 'under load' to have it consistently maintain the full number of requesting threads throughout the test. -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com -Original Message- From: Deepak Shetty [mailto:shet...@gmail.com] Sent: Tuesday, June 12, 2012 5:47 PM To: JMeter Users List Subject: Re: JMeter threading model My test will show a performance change at the end - as the number of total simultaneous threads begins to trail off, the performance will appear to improve. If so , your test needs more than 1 machine to run and the threads on demand wont really help your use case. On Tue, Jun 12, 2012 at 3:42 PM, Robin D. Wilson rwils...@gmail.com wrote: Currently, JMeter will run 100 threads, for 100 iterations each in order to reach 10,000 total passes through my test case. If thread 1 completes its 100 iterations before any of the rest of the threads, it terminates and then I only have 99 threads running until the 10,000 iterations complete. My test will show a performance change at the end - as the number of total simultaneous threads begins to trail off, the performance will appear to improve. For example, I will show the sampler as having completed 9200 requests when the first thread finishes its 100 iterations. This means for the remaining 800 requests, I only have a maximum 99 threads operating. Then at 9300 samples, 19 more threads might have died off - so I only have 80 threads max operating for the remaining 700 requests. As you can imagine, this means that by the end of the test - the performance numbers will start to progressively improve (since fewer threads means less workload on the process being measured, and therefore faster response times). It would be really nice if JMeter just kept a pool of 100 threads operating on requests for the duration of the 10,000 iterations, so that threads would only die off during the final iteration, leaving the server at more-or-less peak load throughout the test. From a code standpoint, this doesn't seem like it would be too hard to setup - just identify how many total iterations need to be run through the thread group, startup the total number of threads you need, and let each thread keep going until all the iterations have been started. (Of course, I say that knowing that I'm just a 'manager' type, and won't be coding it myself...) -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, June 12, 2012 5:02 PM To: JMeter Users List Subject: Re: JMeter threading model On 12 June 2012 22:57, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: On 2012-06-13, at 12:54 AM, sebb wrote: On 12 June 2012 22:06, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: Hi, I figured thread pooling would be revolutionary so I wasn't suggesting that. I would be very useful just delay the creation of a thread until it was asked for. Not sure I understand how it would help to delay the thread creation, except perhaps for the case where the first threads have finished processing by the time the last threads start running samples. Bingo!!! ;-) So what percentage of use cases need to follow this model? Most of the JMeter testing I have done was long running tests where all threads were active for most of the run. Kirk - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
RE: JMeter threading model
sebb wrote: For tests where a CSV data file is not appropriate or convenient, it might make sense to implement a feature which counts total loops and causes the test to stop when a pre-specified limit is reached. Perhaps at thread group level, which already has a duration limit. Or a test element of some kind. At the thread group level is exactly what I'm suggesting... In the meantime, I will setup a csv file with 0- in it (one number per row), and see if I can get that to work like you suggest. Seems a little clunky, but if it works - no issue. -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, June 12, 2012 6:07 PM To: JMeter Users List Subject: Re: JMeter threading model On 12 June 2012 23:42, Robin D. Wilson rwils...@gmail.com wrote: Currently, JMeter will run 100 threads, for 100 iterations each in order to reach 10,000 total passes through my test case. If thread 1 completes its 100 iterations before any of the rest of the threads, it terminates and then I only have 99 threads running until the 10,000 iterations complete. My test will show a performance change at the end - as the number of total simultaneous threads begins to trail off, the performance will appear to improve. For example, I will show the sampler as having completed 9200 requests when the first thread finishes its 100 iterations. This means for the remaining 800 requests, I only have a maximum 99 threads operating. Then at 9300 samples, 19 more threads might have died off - so I only have 80 threads max operating for the remaining 700 requests. As you can imagine, this means that by the end of the test - the performance numbers will start to progressively improve (since fewer threads means less workload on the process being measured, and therefore faster response times). It would be really nice if JMeter just kept a pool of 100 threads operating on requests for the duration of the 10,000 iterations, so that threads would only die off during the final iteration, leaving the server at more-or-less peak load throughout the test. JMeter can do this already. Rather than specify a fixed number of loops, use a CSV Config file with 10,000 entries, and set it to stop the thread (not the test, as that would not let some threads complete) when EOF is reached. For tests where a CSV data file is not appropriate or convenient, it might make sense to implement a feature which counts total loops and causes the test to stop when a pre-specified limit is reached. Perhaps at thread group level, which already has a duration limit. Or a test element of some kind. From a code standpoint, this doesn't seem like it would be too hard to setup - just identify how many total iterations need to be run through the thread group, startup the total number of threads you need, and let each thread keep going until all the iterations have been started. (Of course, I say that knowing that I'm just a 'manager' type, and won't be coding it myself...) -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, June 12, 2012 5:02 PM To: JMeter Users List Subject: Re: JMeter threading model On 12 June 2012 22:57, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: On 2012-06-13, at 12:54 AM, sebb wrote: On 12 June 2012 22:06, Kirk Pepperdine kirk.pepperd...@gmail.com wrote: Hi, I figured thread pooling would be revolutionary so I wasn't suggesting that. I would be very useful just delay the creation of a thread until it was asked for. Not sure I understand how it would help to delay the thread creation, except perhaps for the case where the first threads have finished processing by the time the last threads start running samples. Bingo!!! ;-) So what percentage of use cases need to follow this model? Most of the JMeter testing I have done was long running tests where all threads were active for most of the run. Kirk - 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 - 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: JMeter threading model
On 13 June 2012 01:14, Anthony Johnson ans...@gmail.com wrote:
On Tue, Jun 12, 2012 at 7:06 PM, sebb seb...@gmail.com wrote:
On 12 June 2012 23:42, Robin D. Wilson rwils...@gmail.com wrote:
Currently, JMeter will run 100 threads, for 100 iterations each in order
to reach 10,000 total passes through my test case. If
thread 1 completes its 100 iterations before any of the rest of the
threads, it terminates and then I only have 99 threads running
until the 10,000 iterations complete. My test will show a performance
change at the end - as the number of total simultaneous
threads begins to trail off, the performance will appear to improve. For
example, I will show the sampler as having completed 9200
requests when the first thread finishes its 100 iterations. This means
for the remaining 800 requests, I only have a maximum 99
threads operating. Then at 9300 samples, 19 more threads might have died
off - so I only have 80 threads max operating for the
remaining 700 requests. As you can imagine, this means that by the end
of the test - the performance numbers will start to
progressively improve (since fewer threads means less workload on the
process being measured, and therefore faster response times).
It would be really nice if JMeter just kept a pool of 100 threads
operating on requests for the duration of the 10,000 iterations,
so that threads would only die off during the final iteration, leaving
the server at more-or-less peak load throughout the test.
JMeter can do this already.
Rather than specify a fixed number of loops, use a CSV Config file
with 10,000 entries, and set it to stop the thread (not the test, as
that would not let some threads complete) when EOF is reached.
For tests where a CSV data file is not appropriate or convenient, it
might make sense to implement a feature which counts total loops and
causes the test to stop when a pre-specified limit is reached. Perhaps
at thread group level, which already has a duration limit. Or a test
element of some kind.
It would be nice if their was a drop-in element for this. My team
created a test flow that did exactly this, but it was more work than
it should of been.
There's a drop-in element pair:
+ If Controller, condition: ${__counter(FALSE)} 1
+ + Test Action/Stop Thread.
Theres a trade-off here: the work to add specialised elements (and
documenting/maintaining them) versus the user needing to combine
existing elements to perform the same function. And of course the more
elements there are, the more the user needs to read to find the exact
element they need.
From a code standpoint, this doesn't seem like it would be too hard to
setup - just identify how many total iterations need to be
run through the thread group, startup the total number of threads you
need, and let each thread keep going until all the iterations
have been started. (Of course, I say that knowing that I'm just a
'manager' type, and won't be coding it myself...)
--
Robin D. Wilson
Sr. Director of Web Development
KingsIsle Entertainment, Inc.
VOICE: 512-777-1861
www.KingsIsle.com
-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: Tuesday, June 12, 2012 5:02 PM
To: JMeter Users List
Subject: Re: JMeter threading model
On 12 June 2012 22:57, Kirk Pepperdine kirk.pepperd...@gmail.com
wrote:
On 2012-06-13, at 12:54 AM, sebb wrote:
On 12 June 2012 22:06, Kirk Pepperdine kirk.pepperd...@gmail.com
wrote:
Hi,
I figured thread pooling would be revolutionary so I wasn't
suggesting that. I would be very useful just delay the creation of a
thread until it was asked for.
Not sure I understand how it would help to delay the thread creation,
except perhaps for the case where the first threads have finished
processing by the time the last threads start running samples.
Bingo!!! ;-)
So what percentage of use cases need to follow this model?
Most of the JMeter testing I have done was long running tests where
all threads were active for most of the run.
Kirk
-
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
-
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
-
To
