Summary Report Listener results
I'm seeing some results in the Summary Report listener that doesn't really make sense to me. The test runs 200 concurrent users all requesting the same resource for 60 seconds. Here are the Summary Report Listener results: Num requests: 101243 Average: 118 Min: 5 Max: 27743 Std dev: 349 Error: 0% Throughput: 1681/sec KB/sec: 8210 Average bytes: 5000 It says the throughput is 1681 transactions per second. This seems to make sense since 101243 / 60 = 1687. However, this means that on average each transaction should take about 1/1681 * 1000 = 0.59 ms. It makes sense to me that each request would take less than 1 ms if you are doing more than 1000 transactions per second. However, the minimum transaction time listed is 5 ms. Can someone explain this to me? - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Summary Report Listener results
Oh I see. The throughput accounts for all threads while the average transaction time does not. That makes a lot of sense actually. Thank you. On Mon, Oct 10, 2011 at 6:29 PM, Deepak Shetty shet...@gmail.com wrote: you arent factoring in that you are running 200 threads in parallel. 1681 transactions per second for 200 concurrent requests works out to 1681/200 = 9 requests per second per thread. which means 1000/9 milliseconds per request(assuming no delays) about 111 ms on average (118 in your case) regards deepak On Mon, Oct 10, 2011 at 4:20 PM, E S electric.or.sh...@gmail.com wrote: I'm seeing some results in the Summary Report listener that doesn't really make sense to me. The test runs 200 concurrent users all requesting the same resource for 60 seconds. Here are the Summary Report Listener results: Num requests: 101243 Average: 118 Min: 5 Max: 27743 Std dev: 349 Error: 0% Throughput: 1681/sec KB/sec: 8210 Average bytes: 5000 It says the throughput is 1681 transactions per second. This seems to make sense since 101243 / 60 = 1687. However, this means that on average each transaction should take about 1/1681 * 1000 = 0.59 ms. It makes sense to me that each request would take less than 1 ms if you are doing more than 1000 transactions per second. However, the minimum transaction time listed is 5 ms. Can someone explain this to me? - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Up to date values without CSV config
Thanks for the help. The __time() function is exactly what I wanted. Unfortunately, for the other value (the calculated one), I need access to cryptographic libraries. It looks like I could use either javascript or beanshell as long as they support importing third party libraries, but frankly I think it's just too much work to figure out at this point. I think I'll stick with the CSV Data Set Config element for now. It'll probably be faster than interpreting javascript or Java on the fly anyway. On Thu, Sep 29, 2011 at 6:55 PM, Deepak Shetty shet...@gmail.com wrote: you have __time function and javascript/beanshell in which you can write code to calculate values in. You can store these as variables or properties for all the urls to use. regards deepak On Thu, Sep 29, 2011 at 4:50 PM, E S electric.or.sh...@gmail.com wrote: I have to include two query string parameters in my URLs. One of them is a timestamp and the other is a calculated value based on the timestamp. All the URLs can use the same two values. The tricky part is that the server is validating both of these values and the timestamp must be fairly up to date (within 30 minutes) or the server will reject the request. Currently, I am achieving this by writing a Python script that will get a the current timestamp, calculate the second value, and and output both of them to a one line CSV file, which JMeter will read in using a CSV Data Set Config element. This works fine except I have to re-create the CSV file every 30 minutes or the timestamp gets stale. I think I know the answer to this, but is there any other way to solve this that doesn't require me to keep an up to date CSV file laying around? - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Up to date values without CSV config
I have to include two query string parameters in my URLs. One of them is a timestamp and the other is a calculated value based on the timestamp. All the URLs can use the same two values. The tricky part is that the server is validating both of these values and the timestamp must be fairly up to date (within 30 minutes) or the server will reject the request. Currently, I am achieving this by writing a Python script that will get a the current timestamp, calculate the second value, and and output both of them to a one line CSV file, which JMeter will read in using a CSV Data Set Config element. This works fine except I have to re-create the CSV file every 30 minutes or the timestamp gets stale. I think I know the answer to this, but is there any other way to solve this that doesn't require me to keep an up to date CSV file laying around? - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Make JMeter report error messages in console
No, the error messages are not being written to the jmeter.log file. The only way I was able to get any kind of real time feedback on this was to add the JMeterPlugins Console Status Logger (thanks for the help Andrey). I find this a little surprising. I think this would be a good candidate for a simple JMeter feature. Seems like have an option to see failed requests as they occur would be valuable. Would have saved me a lot of time and frustration, I know that much. On Wed, Sep 14, 2011 at 4:01 PM, sebb seb...@gmail.com wrote: On 14 September 2011 20:34, Oliver Lloyd oliver_ll...@hotmail.com wrote: You could also tail jmeter.log. But are the errors being logged? Sampler errors are generally only visible in the sample result file or visualisers. - http://www.http503.com/ -- View this message in context: http://jmeter.512774.n5.nabble.com/Make-JMeter-report-error-messages-in-console-tp4803852p4804129.html Sent from the JMeter - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Constant throughput timer not giving expected results
I'm seeing a jar file in the lib directory called commons-httpclient-3.1, so I assume I'm using HttpClient 3.1. What do you mean when you say it might be related to timing? On Wed, Sep 14, 2011 at 3:45 AM, sebb seb...@gmail.com wrote: On 14 September 2011 04:51, E S electric.or.sh...@gmail.com wrote: To answer your question, on the 6000 req/sec tests where this is no throughput timer, it's about what you would expect, around 30 ms for the average request. So that means each thread can do about 33 request per second and if you have 200 threads that's roughly 6000 requests per second. I did just notice something significant though. I am getting errors on the tests that use the constant throughput timer. Some of the requests (usually around 10%) give the following error: Response code: Non HTTP response code: java.net.NoRouteToHostException Response message: Non HTTP response message: Cannot assign requested address From what I've researched and the evidence I've gathered on the JMeter box, I'm running out of ephemeral ports. I find this strange though since it doesn't happen when I run without the throughput timer. Shouldn't a be running out of ports either way? What is the timer doing that makes me use more ports? If everything else in the plan is the same, then it must just be timing-related, because the timers just wait as needed. If the box is near the limit of ports, then changes in timing might have an effect. Which HTTP sampler are you using? HttpClient4 (in version 2.5; fixed but not yet released) has an unfortunate bug that means it uses up lots of connections; best to use HttpClient3.1. On Tue, Sep 13, 2011 at 3:11 AM, Oliver Lloyd oliver_ll...@hotmail.comwrote: What are the response times when you run these tests? - http://www.http503.com/ -- View this message in context: http://jmeter.512774.n5.nabble.com/Constant-throughput-timer-not-giving-expected-results-tp4784904p4797538.html Sent from the JMeter - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Constant throughput timer not giving expected results
So how do I tell which HttpClient I am using? Is there a config option for that somewhere? I looked in jmeter.conf and saw some comments related to http client 3.x but nothing that looked very definitive. In terms of running out of ephemeral ports, I guess my options are to try to increase the port range, lower the TIME_WAIT value so the ports are freed up faster, or use distributed load generation. Other options? On Wed, Sep 14, 2011 at 12:32 PM, sebb seb...@gmail.com wrote: On 14 September 2011 17:51, E S electric.or.sh...@gmail.com wrote: I'm seeing a jar file in the lib directory called commons-httpclient-3.1, so I assume I'm using HttpClient 3.1. Not necessarily. There were two Http Sampler implementations in JMeter 2.4. These are merged in JMeter 2.5, which has a drop-down list for the implementation. What do you mean when you say it might be related to timing? Depending on timing, the OS may have had time to free up the resources or not. On Wed, Sep 14, 2011 at 3:45 AM, sebb seb...@gmail.com wrote: On 14 September 2011 04:51, E S electric.or.sh...@gmail.com wrote: To answer your question, on the 6000 req/sec tests where this is no throughput timer, it's about what you would expect, around 30 ms for the average request. So that means each thread can do about 33 request per second and if you have 200 threads that's roughly 6000 requests per second. I did just notice something significant though. I am getting errors on the tests that use the constant throughput timer. Some of the requests (usually around 10%) give the following error: Response code: Non HTTP response code: java.net.NoRouteToHostException Response message: Non HTTP response message: Cannot assign requested address From what I've researched and the evidence I've gathered on the JMeter box, I'm running out of ephemeral ports. I find this strange though since it doesn't happen when I run without the throughput timer. Shouldn't a be running out of ports either way? What is the timer doing that makes me use more ports? If everything else in the plan is the same, then it must just be timing-related, because the timers just wait as needed. If the box is near the limit of ports, then changes in timing might have an effect. Which HTTP sampler are you using? HttpClient4 (in version 2.5; fixed but not yet released) has an unfortunate bug that means it uses up lots of connections; best to use HttpClient3.1. On Tue, Sep 13, 2011 at 3:11 AM, Oliver Lloyd oliver_ll...@hotmail.comwrote: What are the response times when you run these tests? - http://www.http503.com/ -- View this message in context: http://jmeter.512774.n5.nabble.com/Constant-throughput-timer-not-giving-expected-results-tp4784904p4797538.html Sent from the JMeter - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Make JMeter report error messages in console
I was recently running JMeter is headless mode and got a bunch of errors because I was running out of ephemeral ports. However, while JMeter was running, it gave me no indication of this. I had to view the results in either the Summary Report or View Results Tree listener before I realized what was going on. Is it possible to set it up so that I get error messages on the console as they occur? - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Constant throughput timer not giving expected results
I am using JMeter 2.4 r961953. On Wed, Sep 14, 2011 at 1:18 PM, Deepak Shetty shet...@gmail.com wrote: if you are using JMeter 2.5 on the HTTP Sampler , there is a drop down named implementation On Wed, Sep 14, 2011 at 11:06 AM, E S electric.or.sh...@gmail.com wrote: So how do I tell which HttpClient I am using? Is there a config option for that somewhere? I looked in jmeter.conf and saw some comments related to http client 3.x but nothing that looked very definitive. In terms of running out of ephemeral ports, I guess my options are to try to increase the port range, lower the TIME_WAIT value so the ports are freed up faster, or use distributed load generation. Other options? On Wed, Sep 14, 2011 at 12:32 PM, sebb seb...@gmail.com wrote: On 14 September 2011 17:51, E S electric.or.sh...@gmail.com wrote: I'm seeing a jar file in the lib directory called commons-httpclient-3.1, so I assume I'm using HttpClient 3.1. Not necessarily. There were two Http Sampler implementations in JMeter 2.4. These are merged in JMeter 2.5, which has a drop-down list for the implementation. What do you mean when you say it might be related to timing? Depending on timing, the OS may have had time to free up the resources or not. On Wed, Sep 14, 2011 at 3:45 AM, sebb seb...@gmail.com wrote: On 14 September 2011 04:51, E S electric.or.sh...@gmail.com wrote: To answer your question, on the 6000 req/sec tests where this is no throughput timer, it's about what you would expect, around 30 ms for the average request. So that means each thread can do about 33 request per second and if you have 200 threads that's roughly 6000 requests per second. I did just notice something significant though. I am getting errors on the tests that use the constant throughput timer. Some of the requests (usually around 10%) give the following error: Response code: Non HTTP response code: java.net.NoRouteToHostException Response message: Non HTTP response message: Cannot assign requested address From what I've researched and the evidence I've gathered on the JMeter box, I'm running out of ephemeral ports. I find this strange though since it doesn't happen when I run without the throughput timer. Shouldn't a be running out of ports either way? What is the timer doing that makes me use more ports? If everything else in the plan is the same, then it must just be timing-related, because the timers just wait as needed. If the box is near the limit of ports, then changes in timing might have an effect. Which HTTP sampler are you using? HttpClient4 (in version 2.5; fixed but not yet released) has an unfortunate bug that means it uses up lots of connections; best to use HttpClient3.1. On Tue, Sep 13, 2011 at 3:11 AM, Oliver Lloyd oliver_ll...@hotmail.comwrote: What are the response times when you run these tests? - http://www.http503.com/ -- View this message in context: http://jmeter.512774.n5.nabble.com/Constant-throughput-timer-not-giving-expected-results-tp4784904p4797538.html Sent from the JMeter - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Constant throughput timer not giving expected results
Ah, you're right. I'm using HTTP Request. I had not even noticed the HTTPClient sampler. Sorry for the confusion. On Wed, Sep 14, 2011 at 2:19 PM, sebb seb...@gmail.com wrote: On 14 September 2011 19:36, Deepak Shetty shet...@gmail.com wrote: then you are on httpclient 3.1 Perhaps we are talking about different things. JMeter 2.4 supports 2 different HTTP Samplers: - HTTP Request (this is Java) - HTTP Request HTTPClient (this is HttpClient 3.1) which of these is being used? On Wed, Sep 14, 2011 at 11:34 AM, E S electric.or.sh...@gmail.com wrote: I am using JMeter 2.4 r961953. On Wed, Sep 14, 2011 at 1:18 PM, Deepak Shetty shet...@gmail.com wrote: if you are using JMeter 2.5 on the HTTP Sampler , there is a drop down named implementation On Wed, Sep 14, 2011 at 11:06 AM, E S electric.or.sh...@gmail.com wrote: So how do I tell which HttpClient I am using? Is there a config option for that somewhere? I looked in jmeter.conf and saw some comments related to http client 3.x but nothing that looked very definitive. In terms of running out of ephemeral ports, I guess my options are to try to increase the port range, lower the TIME_WAIT value so the ports are freed up faster, or use distributed load generation. Other options? On Wed, Sep 14, 2011 at 12:32 PM, sebb seb...@gmail.com wrote: On 14 September 2011 17:51, E S electric.or.sh...@gmail.com wrote: I'm seeing a jar file in the lib directory called commons-httpclient-3.1, so I assume I'm using HttpClient 3.1. Not necessarily. There were two Http Sampler implementations in JMeter 2.4. These are merged in JMeter 2.5, which has a drop-down list for the implementation. What do you mean when you say it might be related to timing? Depending on timing, the OS may have had time to free up the resources or not. On Wed, Sep 14, 2011 at 3:45 AM, sebb seb...@gmail.com wrote: On 14 September 2011 04:51, E S electric.or.sh...@gmail.com wrote: To answer your question, on the 6000 req/sec tests where this is no throughput timer, it's about what you would expect, around 30 ms for the average request. So that means each thread can do about 33 request per second and if you have 200 threads that's roughly 6000 requests per second. I did just notice something significant though. I am getting errors on the tests that use the constant throughput timer. Some of the requests (usually around 10%) give the following error: Response code: Non HTTP response code: java.net.NoRouteToHostException Response message: Non HTTP response message: Cannot assign requested address From what I've researched and the evidence I've gathered on the JMeter box, I'm running out of ephemeral ports. I find this strange though since it doesn't happen when I run without the throughput timer. Shouldn't a be running out of ports either way? What is the timer doing that makes me use more ports? If everything else in the plan is the same, then it must just be timing-related, because the timers just wait as needed. If the box is near the limit of ports, then changes in timing might have an effect. Which HTTP sampler are you using? HttpClient4 (in version 2.5; fixed but not yet released) has an unfortunate bug that means it uses up lots of connections; best to use HttpClient3.1. On Tue, Sep 13, 2011 at 3:11 AM, Oliver Lloyd oliver_ll...@hotmail.comwrote: What are the response times when you run these tests? - http://www.http503.com/ -- View this message in context: http://jmeter.512774.n5.nabble.com/Constant-throughput-timer-not-giving-expected-results-tp4784904p4797538.html Sent from the JMeter - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h
Re: Constant throughput timer not giving expected results
To answer your question, on the 6000 req/sec tests where this is no throughput timer, it's about what you would expect, around 30 ms for the average request. So that means each thread can do about 33 request per second and if you have 200 threads that's roughly 6000 requests per second. I did just notice something significant though. I am getting errors on the tests that use the constant throughput timer. Some of the requests (usually around 10%) give the following error: Response code: Non HTTP response code: java.net.NoRouteToHostException Response message: Non HTTP response message: Cannot assign requested address From what I've researched and the evidence I've gathered on the JMeter box, I'm running out of ephemeral ports. I find this strange though since it doesn't happen when I run without the throughput timer. Shouldn't a be running out of ports either way? What is the timer doing that makes me use more ports? On Tue, Sep 13, 2011 at 3:11 AM, Oliver Lloyd oliver_ll...@hotmail.comwrote: What are the response times when you run these tests? - http://www.http503.com/ -- View this message in context: http://jmeter.512774.n5.nabble.com/Constant-throughput-timer-not-giving-expected-results-tp4784904p4797538.html Sent from the JMeter - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Constant throughput timer not giving expected results
Well I did some more testing and I have to say that I'm still confused. All I can figure is that I am misunderstanding how the constant throughput timer works. I was able to configure the throughput timer to get the same results as I did without it (6000 req/sec) but I had to set the total throughput value on the timer to be really high (about 2,000,000 req/min). I would think the number should be around 360,000 but for some reason that's not enough. This is using the all active threads in the current thread group mode. I tried using the this thread only mode. I set the test up with 200 threads and the throughput timer to have each thread run at 1800 req/min. According to my understanding, that is 200 threads each pumping out 30 requests per second for a total of 6000 requests per second. Under this configuration my total throughput was only 1400 requests per second. I had to jack up the timer's setting to 22,000 req/min to get the proper throughput. I don't get this. Clearly the server is capable of providing the throughput that I'm looking for. Why do I have to set the timers in such weird ways to get the throughput to the desired level? On Fri, Sep 9, 2011 at 6:57 AM, sebb seb...@gmail.com wrote: On 9 September 2011 04:31, E S electric.or.sh...@gmail.com wrote: I'm having some trouble getting the Constant Throughput Timer to work the way I want in certain cases. I have a single thread group of 100 threads, all of which are requesting the same resource over and over for 1 minute. I attached a Constant Throughput Timer on the thread group and ran a series tests with the throughput throttled at higher and higher levels such as 6000, 8000, 1, etc. Here is a table showing the throughput timer settings and the actual number of requests that the server under test responded to: thruput-setting..actual-requests-served 36,000.36,000 48,000.48,000 60,000.60,000 72,000.60,000 84,000.60,000 So it looks like the server under test simply can't respond to more than 60,000 requests per minute right? However, when I disable the throughput timer I get way higher throughput, something like 350,000 requests per minute. What's going on here? Why is the throughput timer giving me these results? Is it possible that JMeter is spending so much time trying to keep the throughput at the right level that it doesn't have enough cycles left to dedicate to actual requests? I tried distributing the load across multiple load generators but it didn't seem to help. The results above have the throughput timer configured using Calculate Throughput based on = all active threads in current thread group. I tried changing this to all active threads in current thread group (shared) and I get the maximum results of 350,000 as if the throughput timer was not even there. I must admit I don't understand the difference between the two settings, but neither result sounds right. Any ideas about this? Create a test plan using the Java Sampler with timer settings that correspond to your server. Run a test with CTT disabled and check you get the desired throughput (use Summary Listener). You can then experiment with the CTT without needing to take server and network behaviour into account. - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Constant throughput timer not giving expected results
I'm having some trouble getting the Constant Throughput Timer to work the way I want in certain cases. I have a single thread group of 100 threads, all of which are requesting the same resource over and over for 1 minute. I attached a Constant Throughput Timer on the thread group and ran a series tests with the throughput throttled at higher and higher levels such as 6000, 8000, 1, etc. Here is a table showing the throughput timer settings and the actual number of requests that the server under test responded to: thruput-setting..actual-requests-served 36,000.36,000 48,000.48,000 60,000.60,000 72,000.60,000 84,000.60,000 So it looks like the server under test simply can't respond to more than 60,000 requests per minute right? However, when I disable the throughput timer I get way higher throughput, something like 350,000 requests per minute. What's going on here? Why is the throughput timer giving me these results? Is it possible that JMeter is spending so much time trying to keep the throughput at the right level that it doesn't have enough cycles left to dedicate to actual requests? I tried distributing the load across multiple load generators but it didn't seem to help. The results above have the throughput timer configured using Calculate Throughput based on = all active threads in current thread group. I tried changing this to all active threads in current thread group (shared) and I get the maximum results of 350,000 as if the throughput timer was not even there. I must admit I don't understand the difference between the two settings, but neither result sounds right. Any ideas about this?
Re: Programmatic access to thread group loop count
Okay, I see what you mean now. For the sake of posterity, I'll explain it in
a little more detail. I defined a variable on the test plan, as you said,
called LOOPS. Then in the Thread Group I set the value in the Loop Count
box to ${LOOPS}. Then in the code, when I want to access this value I use
JMeterVariables vars = getThreadContext().getVariables();
int numLoops = Integer.parseInt(vars.get(LOOPS));
To be honest, I think I like the other method better because I don't have to
maintain the extra variable, but this is a good alternative if it's needed.
Thanks.
On Thu, Jul 21, 2011 at 7:03 PM, sebb seb...@gmail.com wrote:
Define a variable for the loop count on the Test Plan.
Use that wherever you want to know the loop count.
On 21 July 2011 23:59, E S electric.or.sh...@gmail.com wrote:
Can you expound on that a little? I'm not sure I follow.
On Thu, Jul 21, 2011 at 4:09 PM, sebb seb...@gmail.com wrote:
Another way to do this would be to use a variable for the loop count.
On 21 July 2011 20:25, E S electric.or.sh...@gmail.com wrote:
FYI, it looks like this can be done with the following code within a
sampler:
Controller ctrl =
getThreadContext().getThreadGroup().getSamplerController();
LoopController loopCtrl = (LoopController)ctrl;
int loopCount = loopCtrl.getLoops();
The getSamplerController() method returns a reference to the
Controller
interface, which doesn't know anything about loops. However, it
appears
that
the thread group works with a LoopController by default so the
downcast
works. I'm not sure what, if anything, can be done to invalidate that
assumption.
If you select forever or use the scheduler feature on the thread
group,
loop count will be -1.
On Tue, Jul 19, 2011 at 9:42 AM, E S electric.or.sh...@gmail.com
wrote:
I have a custom sampler that I'm writing. Is it possible to
programmatically access the thread group's loop count from within the
sampler? I can do the following:
this.getThreadContext().getThreadGroup()
From that I can get the thread group name, comments, and number of
threads
but I don't see a property for the loop count.
-
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
-
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Programmatic access to thread group loop count
FYI, it looks like this can be done with the following code within a sampler: Controller ctrl = getThreadContext().getThreadGroup().getSamplerController(); LoopController loopCtrl = (LoopController)ctrl; int loopCount = loopCtrl.getLoops(); The getSamplerController() method returns a reference to the Controller interface, which doesn't know anything about loops. However, it appears that the thread group works with a LoopController by default so the downcast works. I'm not sure what, if anything, can be done to invalidate that assumption. If you select forever or use the scheduler feature on the thread group, loop count will be -1. On Tue, Jul 19, 2011 at 9:42 AM, E S electric.or.sh...@gmail.com wrote: I have a custom sampler that I'm writing. Is it possible to programmatically access the thread group's loop count from within the sampler? I can do the following: this.getThreadContext().getThreadGroup() From that I can get the thread group name, comments, and number of threads but I don't see a property for the loop count.
Re: Programmatic access to thread group loop count
Can you expound on that a little? I'm not sure I follow. On Thu, Jul 21, 2011 at 4:09 PM, sebb seb...@gmail.com wrote: Another way to do this would be to use a variable for the loop count. On 21 July 2011 20:25, E S electric.or.sh...@gmail.com wrote: FYI, it looks like this can be done with the following code within a sampler: Controller ctrl = getThreadContext().getThreadGroup().getSamplerController(); LoopController loopCtrl = (LoopController)ctrl; int loopCount = loopCtrl.getLoops(); The getSamplerController() method returns a reference to the Controller interface, which doesn't know anything about loops. However, it appears that the thread group works with a LoopController by default so the downcast works. I'm not sure what, if anything, can be done to invalidate that assumption. If you select forever or use the scheduler feature on the thread group, loop count will be -1. On Tue, Jul 19, 2011 at 9:42 AM, E S electric.or.sh...@gmail.com wrote: I have a custom sampler that I'm writing. Is it possible to programmatically access the thread group's loop count from within the sampler? I can do the following: this.getThreadContext().getThreadGroup() From that I can get the thread group name, comments, and number of threads but I don't see a property for the loop count. - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Programmatic access to thread group loop count
I have a custom sampler that I'm writing. Is it possible to programmatically access the thread group's loop count from within the sampler? I can do the following: this.getThreadContext().getThreadGroup() From that I can get the thread group name, comments, and number of threads but I don't see a property for the loop count.
Null properties
I have a number of TestBean properties on a custom sampler that I have written. I would like some of the integer properties to be optional. I had thought about achieving this by using the Integer class as the type instead of int like this: private Integer someProp; get... set... ... p = property(someProp); p.setValue(NOT_UNDEFINED, Boolean.FALSE); p.setValue(NOT_EXPRESSION, Boolean.TRUE); p.setValue(NOT_OTHER, Boolean.FALSE); However, when I do this, nothing shows up in the interface. I tried changing the property type to int but I just get errors stating The text you entered is not valid for this property. I suppose could just make everything a String instead of the actual data types, but I'd rather avoid that if possible. Ideas?
Re: Set sampler start/end time directly
I see, so call addSubResult() will adjust the parent's end time for you.
Well that solves half the problem. Of course you still have the problem
where the child threads don't start until long after the parent results's
sampleStart() is called which could also lead to a large discrepancy in
time. I would think that addSubResult() would adjust the parent start time
in addition to the end time, but it doesn't seem to. Maybe I'm
misunderstanding how you use results and subresults?
On Tue, Jun 28, 2011 at 5:26 PM, sebb seb...@gmail.com wrote:
On 28 June 2011 23:18, E S electric.or.sh...@gmail.com wrote:
I have a custom sampler I wrote that spins off a number of threads to do
the
actual requests, the results of which are added as sub results. So if
your
test plan ran 5 users and each user made 10 requests from their virtual
browser, you'd have 5 results with 10 sub results under each one. The
problem I am having is setting the parent sampler start and end times
properly. Currently, I am starting the parent sampler before any of the
sub-threads start and ending it when all of the sub-threads have
finished.
However, I'm getting times that are way too high in the parent sampler.
My
guess is that it has to do with thread scheduling. For example, maybe
there
are just so many threads running that it can't get to each one quick
enough
to set the timer off at a reasonable time after the last request
finished.
What timer?
An easy way to solve this would be to loop through the sub results and
get
the earliest start time and latest end time and set the parent result's
start and end time equal to those. Unfortunately, I don't see a way to do
this. The API only appears to expose the sampleStart() and sampleEnd()
methods. You can't directly set the start and end times.
That is deliberate.
Any ideas for a work around on this?
http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#addSubResult%28org.apache.jmeter.samplers.SampleResult%29
should do what you need.
For reference, here is a watered down version of my sampler code:
public SampleResult sample(Entry e) {
//pool of threads to do sub-requests
ListThread requestRunners = new ArrayListThread();
//4 because most browsers support 4 simultaneous requests
for (int i = 0; i 4; i++)
requestRunners.add(new Thread(new RequestRunner());
result.sampleStart();
//start all the sub-requests
for (Thread runner : requestRunners)
runner.start();
//wait for all sub-requests to finish
for (Thread runner : requestRunners) {
runner.join();
//this doesn't work right because too much time has passed since the
last
sub-request came back in and the next line of code
result.sampleEnd();
result.setSuccessful(allResultsSuccessful(result.getSubResults()));
return result;
}
-
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Set sampler start/end time directly
I can, I just have write code to coordinate the child threads so that the
first one that runs starts the parent result timer and and none of the
others do. I was just hoping the system would take care of that for me like
it did with the end time. Not a huge deal.
On Wed, Jun 29, 2011 at 1:39 PM, sebb seb...@gmail.com wrote:
On 29 June 2011 17:41, E S electric.or.sh...@gmail.com wrote:
I see, so call addSubResult() will adjust the parent's end time for you.
Well that solves half the problem. Of course you still have the problem
where the child threads don't start until long after the parent results's
sampleStart() is called which could also lead to a large discrepancy in
time. I would think that addSubResult() would adjust the parent start
time
in addition to the end time, but it doesn't seem to. Maybe I'm
misunderstanding how you use results and subresults?
If you are writing your own sampler, you can start the child threads
at the same time as starting the main sample.
On Tue, Jun 28, 2011 at 5:26 PM, sebb seb...@gmail.com wrote:
On 28 June 2011 23:18, E S electric.or.sh...@gmail.com wrote:
I have a custom sampler I wrote that spins off a number of threads to
do
the
actual requests, the results of which are added as sub results. So if
your
test plan ran 5 users and each user made 10 requests from their
virtual
browser, you'd have 5 results with 10 sub results under each one. The
problem I am having is setting the parent sampler start and end times
properly. Currently, I am starting the parent sampler before any of
the
sub-threads start and ending it when all of the sub-threads have
finished.
However, I'm getting times that are way too high in the parent
sampler.
My
guess is that it has to do with thread scheduling. For example, maybe
there
are just so many threads running that it can't get to each one quick
enough
to set the timer off at a reasonable time after the last request
finished.
What timer?
An easy way to solve this would be to loop through the sub results and
get
the earliest start time and latest end time and set the parent
result's
start and end time equal to those. Unfortunately, I don't see a way to
do
this. The API only appears to expose the sampleStart() and sampleEnd()
methods. You can't directly set the start and end times.
That is deliberate.
Any ideas for a work around on this?
http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#addSubResult%28org.apache.jmeter.samplers.SampleResult%29
should do what you need.
For reference, here is a watered down version of my sampler code:
public SampleResult sample(Entry e) {
//pool of threads to do sub-requests
ListThread requestRunners = new ArrayListThread();
//4 because most browsers support 4 simultaneous requests
for (int i = 0; i 4; i++)
requestRunners.add(new Thread(new RequestRunner());
result.sampleStart();
//start all the sub-requests
for (Thread runner : requestRunners)
runner.start();
//wait for all sub-requests to finish
for (Thread runner : requestRunners) {
runner.join();
//this doesn't work right because too much time has passed since the
last
sub-request came back in and the next line of code
result.sampleEnd();
result.setSuccessful(allResultsSuccessful(result.getSubResults()));
return result;
}
-
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
-
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Set sampler start/end time directly
I have a custom sampler I wrote that spins off a number of threads to do the
actual requests, the results of which are added as sub results. So if your
test plan ran 5 users and each user made 10 requests from their virtual
browser, you'd have 5 results with 10 sub results under each one. The
problem I am having is setting the parent sampler start and end times
properly. Currently, I am starting the parent sampler before any of the
sub-threads start and ending it when all of the sub-threads have finished.
However, I'm getting times that are way too high in the parent sampler. My
guess is that it has to do with thread scheduling. For example, maybe there
are just so many threads running that it can't get to each one quick enough
to set the timer off at a reasonable time after the last request finished.
An easy way to solve this would be to loop through the sub results and get
the earliest start time and latest end time and set the parent result's
start and end time equal to those. Unfortunately, I don't see a way to do
this. The API only appears to expose the sampleStart() and sampleEnd()
methods. You can't directly set the start and end times.
Any ideas for a work around on this?
For reference, here is a watered down version of my sampler code:
public SampleResult sample(Entry e) {
//pool of threads to do sub-requests
ListThread requestRunners = new ArrayListThread();
//4 because most browsers support 4 simultaneous requests
for (int i = 0; i 4; i++)
requestRunners.add(new Thread(new RequestRunner());
result.sampleStart();
//start all the sub-requests
for (Thread runner : requestRunners)
runner.start();
//wait for all sub-requests to finish
for (Thread runner : requestRunners) {
runner.join();
//this doesn't work right because too much time has passed since the last
sub-request came back in and the next line of code
result.sampleEnd();
result.setSuccessful(allResultsSuccessful(result.getSubResults()));
return result;
}
Once only per thread group
I have a setup in which I have a single thread group that runs 50 threads and each of those threads runs one HTTP Request like this: Test Plan -- Thread Group (50 threads running one time each) -- -- HTTP Request -- -- View Results Tree I need to add another HTTP Request but it has to execute one time as the very first thing for the entire test plan. The Once Only Controller doesn't work because it executes once per thread, not per thread group. I tried adding another thread group above the first one like this: Test Plan -- Thread Group (1 thread doing one thing, must run before the one below it) -- -- HTTP Request -- Thread Group (50 threads running one time each) -- -- HTTP Request -- -- View Results Tree However, I would need to make sure the first thread group executes in full before the second one starts and I couldn't figure out how to do that. Is there another way to achieve this?
Re: Once only per thread group
Perfect, thank you. On Wed, Jun 22, 2011 at 12:12 PM, Deepak Shetty shet...@gmail.com wrote: http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Test_Plan RunThread Groups consecutively. The other option is an IF controller which is true only when the thread number is one , followed by a dummy sampler .which has sync timer (with a value = total number of threadS) regards deepak On Wed, Jun 22, 2011 at 10:06 AM, E S electric.or.sh...@gmail.com wrote: I have a setup in which I have a single thread group that runs 50 threads and each of those threads runs one HTTP Request like this: Test Plan -- Thread Group (50 threads running one time each) -- -- HTTP Request -- -- View Results Tree I need to add another HTTP Request but it has to execute one time as the very first thing for the entire test plan. The Once Only Controller doesn't work because it executes once per thread, not per thread group. I tried adding another thread group above the first one like this: Test Plan -- Thread Group (1 thread doing one thing, must run before the one below it) -- -- HTTP Request -- Thread Group (50 threads running one time each) -- -- HTTP Request -- -- View Results Tree However, I would need to make sure the first thread group executes in full before the second one starts and I couldn't figure out how to do that. Is there another way to achieve this?
Re: Concurrent HTTP requests to simulate AJAX client
Yes, that does seem to have worked. I spin off the sub-threads then wait using thread.join() until all the sub-threads are done. Then I call result.sampleEnd() on the outer sample. Thank you, that was very helpful. On Mon, Jun 20, 2011 at 12:43 PM, Bruce Ide flyingrhenqu...@gmail.comwrote: I believe you can hang subsamples off of the SampleResult object that gets created. Your sampler would just need to block until all subsamples have been returned, and it would have to know how to assemble them in the final sample (Which shouldn't be a terribly big deal.) I haven't done anything with subsamples myself, I've just noted that there seems to be that capability while digging around in the source code. -- Bruce Ide flyingrhenqu...@gmail.com
Re: Concurrent HTTP requests to simulate AJAX client
After looking into it further, it's looking like my approach of writing a custom sampler to spin off sub-threads to do individual concurrent requests will not work. Correct me if I'm wrong, but JMeter bases its reporting off the one SampleResult object returned from the sampler's sample() method. So if each individual run of my sampler ran multiple requests via a number of sub-threads, I have no way of reporting the results of each of those individual requests. The best I could do would be to aggregate all the results of the individual thread requests in some manner and return that as the sampler's result. Is that correct? Dave On Thu, Jun 16, 2011 at 12:15 PM, Deepak Shetty shet...@gmail.com wrote: Hi I played around with this awhile ago - perhaps you may get some hints http://theworkaholic.blogspot.com/2010/11/jmeter-and-ajax-part-i.html regards deepak On Thu, Jun 16, 2011 at 8:59 AM, E S electric.or.sh...@gmail.com wrote: Thanks for the advice. I did implement a test using the CSV Data Set in the manner you speak of. That was a good first step, but I'm having trouble getting it to model exactly what I'm looking for. I agree that from the app's perspective, it doesn't know/care which thread is sending which request, but it does care that the requests are grouped together with respect physical locality on the map (adjacent tiles are requested in groups of 4). I think it would be difficult to craft the CSV files in such as way as to make it dole out the proper requests so that it looked like multiple different users are requesting tiles from different parts of the map at once, but still maintaining the spatial locality aspect. It would have to interleave groups of requests for different portions of the map and use the Synchronizing Timer to group threads together to bundle up blocks of 4 request. Sounds tricky. It just seems way easier to write my code to do this by spinning off child threads in each user (JMeter) thread. Then when I want to ramp up the user load I just add more JMeter threads. Another approach I was thinking of taking was to write my own Java app outside of JMeter to do this and to simply have it output a valid log.jtl file, which I could view using JMeter. Not sure how well that will work, but it's something I might have to consider if writing the sampler is going to be difficult. Dave On Mon, Jun 13, 2011 at 5:25 PM, Bruce Ide flyingrhenqu...@gmail.com wrote: You'd determine which tiles you wanted to request in advance, and you'd put that information in a CSV file. Then you'd write a test that requests a tile using information from the CSV data set. When you ramp up the number of users (running threads) in your thread group, the CSV data set would parcel your requests out equally among all threads. It does this one line at a time in the file, thread 1 gets the first line, thread 2 gets the second line, and so forth. As long as you build your CSV files to access adjacent tiles, it should look like a user with a browser to the application. You could even maintain different datasets to simulate light or heavy usage. -- Bruce Ide flyingrhenqu...@gmail.com
Re: Concurrent HTTP requests to simulate AJAX client
Thanks for the advice. I did implement a test using the CSV Data Set in the manner you speak of. That was a good first step, but I'm having trouble getting it to model exactly what I'm looking for. I agree that from the app's perspective, it doesn't know/care which thread is sending which request, but it does care that the requests are grouped together with respect physical locality on the map (adjacent tiles are requested in groups of 4). I think it would be difficult to craft the CSV files in such as way as to make it dole out the proper requests so that it looked like multiple different users are requesting tiles from different parts of the map at once, but still maintaining the spatial locality aspect. It would have to interleave groups of requests for different portions of the map and use the Synchronizing Timer to group threads together to bundle up blocks of 4 request. Sounds tricky. It just seems way easier to write my code to do this by spinning off child threads in each user (JMeter) thread. Then when I want to ramp up the user load I just add more JMeter threads. Another approach I was thinking of taking was to write my own Java app outside of JMeter to do this and to simply have it output a valid log.jtl file, which I could view using JMeter. Not sure how well that will work, but it's something I might have to consider if writing the sampler is going to be difficult. Dave On Mon, Jun 13, 2011 at 5:25 PM, Bruce Ide flyingrhenqu...@gmail.comwrote: You'd determine which tiles you wanted to request in advance, and you'd put that information in a CSV file. Then you'd write a test that requests a tile using information from the CSV data set. When you ramp up the number of users (running threads) in your thread group, the CSV data set would parcel your requests out equally among all threads. It does this one line at a time in the file, thread 1 gets the first line, thread 2 gets the second line, and so forth. As long as you build your CSV files to access adjacent tiles, it should look like a user with a browser to the application. You could even maintain different datasets to simulate light or heavy usage. -- Bruce Ide flyingrhenqu...@gmail.com
Re: Custom Sampler Tutorial
Barrie,
Thanks for sharing your code. I am also currently using the Http Request
sampler, but I don't know of an easy way to simulate the required use cases
with that sampler in conjunction with other elements like timers. Instead of
repeating the whole problem, I'll just point you to another thread in which
I'm already discussing the issue (and why I'm leaning toward a custom
sampler).
http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-user/201106.mbox/%3cbanlktikoej_k-fcigkohp4rggukg3jc...@mail.gmail.com%3E
That's just my original post. There are follow ups as well, but I couldn't
get it to include all those in one link.
Dave
On Wed, Jun 15, 2011 at 6:06 PM, Barrie Treloar baerr...@gmail.com wrote:
On Wed, Jun 15, 2011 at 3:41 PM, Bruce Ide flyingrhenqu...@gmail.com
wrote:
I've written a couple of data elements, a sampler and a post-processor.
Most
of what I picked up came from reading the jmeter source code itself.
That's
probably the best place to start. I'm still not clear on how some of the
UI
stuff works, but that's more due to me not being terribly familiar with
swing than because of jmeter.
The reason there are not tons of examples is because most people are using
HTTP.
Any other testing and you are in the minority.
As Bruce says, its hack away.
What type of Custom Sampler are you writing?
If its a JavaSamplerClient, then here are some notes from my hacking.
* Logging is available by
import org.apache.log.Logger;
private static final Logger LOGGER =
Hierarchy.getDefaultHierarchy().getLoggerFor(YOUR_CLASS.class.getName());
* Threading model is one client per Thread.
If you need state between threads you need to really think hard
about how to implement it.
Our problem was we are modelling the a thick Java client that
connects over UDP.
So something needs to start up a UDP listen port and receive
messages and pass them on to the correct sampler.
We *BROKE* the JMeter threading model and made the ThreadGroup the
client. But we did this knowing the limitations.
Your mileage may vary...
* getDefaultParameters() defines the complete and final set of
parameters available.
The UI has an add button, but this doesn't actually add a new
parameter to the class. There is JIRA about removing that button.
If you want to add a new parameter to your test you must add it to
the Arguments returned by getDefaultParameters().
My personal preference is to set the default value of the parameter
to ${YOUR_PARAMETER_NAME}
e.g.
/**
* See class Javadoc.
*
* @JMeterParameter
*/
public static final String PARAMETER_TIMEOUT = timeout;
public Arguments getDefaultParameters() {
Arguments arguments = new Arguments();
arguments.addArgument(PARAMETER_TIMEOUT, ${TIMEOUT});
...
I also define a constant for the parameter in my Java sampler class
because you will need it to extract the value of the the
JavaSamplerContext in runTest()
I document in the class javadoc what all the parameters mean and
acceptable values.
* create your own factory method for instantiating SampleResults
I found I was setting the same values all the time, so a factory
method saved some duplication.
/**
* Use UTF-8 for encoding of strings
*/
public static final String ENCODING = UTF-8;
public SampleResult newSampleResult() {
SampleResult result = new SampleResult();
result.setDataEncoding(ENCODING);
result.setDataType(SampleResult.TEXT);
return result;
}
* create helper methods for start, success and failure.
/**
* Start the sample request and set the codesamplerData/code to the
* requestData.
*
* @param result
* the sample result to update
* @param requestData
* the request to set as codesamplerData/code
*/
protected void sampleResultStart(SampleResult result, String requestData)
{
result.setSamplerData(requestData);
result.sampleStart();
}
/**
* Set the sample result as codesampleEnd()/code,
* codesetSuccessful(true)/code, codesetResponseCode(OK)/code
and if
* the response is not codenull/code then
* codesetResponseData(response.toString(), ENCODING)/code otherwise
it is
* marked as not requiring a response.
*
* @param result
* sample result to change
* @param response
* the successful result message, may be null.
*/
protected void sampleResultSuccess(SampleResult result,
String response) {
result.sampleEnd();
result.setSuccessful(true);
result.setResponseCode(OK);
if (response != null) {
result.setResponseData(response, ENCODING);
}
else {
result.setResponseData(No response required, ENCODING);
}
}
/**
* Mark the sample result as codesampleEnd/code,
* codesetSuccessful(false)/code and the codesetResponseCode/code
to
* reason.
*
* @param result
* the sample result to change
* @param reason
* the failure
Re: Custom Sampler Tutorial
Barrie,
How did you deploy your sampler so you could actually use it in the JMeter
GUI? I've seen that the guys who wrote jmeter-plugins got it to the point
where you could just drop a jar file into the lib/ext directory and it just
worked. Did you get to the point?
Dave
On Thu, Jun 16, 2011 at 11:17 AM, E S electric.or.sh...@gmail.com wrote:
Barrie,
Thanks for sharing your code. I am also currently using the Http Request
sampler, but I don't know of an easy way to simulate the required use cases
with that sampler in conjunction with other elements like timers. Instead of
repeating the whole problem, I'll just point you to another thread in which
I'm already discussing the issue (and why I'm leaning toward a custom
sampler).
http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-user/201106.mbox/%3cbanlktikoej_k-fcigkohp4rggukg3jc...@mail.gmail.com%3E
That's just my original post. There are follow ups as well, but I couldn't
get it to include all those in one link.
Dave
On Wed, Jun 15, 2011 at 6:06 PM, Barrie Treloar baerr...@gmail.comwrote:
On Wed, Jun 15, 2011 at 3:41 PM, Bruce Ide flyingrhenqu...@gmail.com
wrote:
I've written a couple of data elements, a sampler and a post-processor.
Most
of what I picked up came from reading the jmeter source code itself.
That's
probably the best place to start. I'm still not clear on how some of the
UI
stuff works, but that's more due to me not being terribly familiar with
swing than because of jmeter.
The reason there are not tons of examples is because most people are using
HTTP.
Any other testing and you are in the minority.
As Bruce says, its hack away.
What type of Custom Sampler are you writing?
If its a JavaSamplerClient, then here are some notes from my hacking.
* Logging is available by
import org.apache.log.Logger;
private static final Logger LOGGER =
Hierarchy.getDefaultHierarchy().getLoggerFor(YOUR_CLASS.class.getName());
* Threading model is one client per Thread.
If you need state between threads you need to really think hard
about how to implement it.
Our problem was we are modelling the a thick Java client that
connects over UDP.
So something needs to start up a UDP listen port and receive
messages and pass them on to the correct sampler.
We *BROKE* the JMeter threading model and made the ThreadGroup the
client. But we did this knowing the limitations.
Your mileage may vary...
* getDefaultParameters() defines the complete and final set of
parameters available.
The UI has an add button, but this doesn't actually add a new
parameter to the class. There is JIRA about removing that button.
If you want to add a new parameter to your test you must add it to
the Arguments returned by getDefaultParameters().
My personal preference is to set the default value of the parameter
to ${YOUR_PARAMETER_NAME}
e.g.
/**
* See class Javadoc.
*
* @JMeterParameter
*/
public static final String PARAMETER_TIMEOUT = timeout;
public Arguments getDefaultParameters() {
Arguments arguments = new Arguments();
arguments.addArgument(PARAMETER_TIMEOUT, ${TIMEOUT});
...
I also define a constant for the parameter in my Java sampler class
because you will need it to extract the value of the the
JavaSamplerContext in runTest()
I document in the class javadoc what all the parameters mean and
acceptable values.
* create your own factory method for instantiating SampleResults
I found I was setting the same values all the time, so a factory
method saved some duplication.
/**
* Use UTF-8 for encoding of strings
*/
public static final String ENCODING = UTF-8;
public SampleResult newSampleResult() {
SampleResult result = new SampleResult();
result.setDataEncoding(ENCODING);
result.setDataType(SampleResult.TEXT);
return result;
}
* create helper methods for start, success and failure.
/**
* Start the sample request and set the codesamplerData/code to the
* requestData.
*
* @param result
* the sample result to update
* @param requestData
* the request to set as codesamplerData/code
*/
protected void sampleResultStart(SampleResult result, String requestData)
{
result.setSamplerData(requestData);
result.sampleStart();
}
/**
* Set the sample result as codesampleEnd()/code,
* codesetSuccessful(true)/code, codesetResponseCode(OK)/code
and if
* the response is not codenull/code then
* codesetResponseData(response.toString(), ENCODING)/code otherwise
it is
* marked as not requiring a response.
*
* @param result
* sample result to change
* @param response
* the successful result message, may be null.
*/
protected void sampleResultSuccess(SampleResult result,
String response) {
result.sampleEnd();
result.setSuccessful(true);
result.setResponseCode(OK);
if (response != null) {
result.setResponseData
Re: Custom Sampler Tutorial
Okay, well I got something to deploy and show up in the GUI, but I'm a little confused on the methodology. The tutorial ( http://jakarta.apache.org/jmeter/extending/jmeter_tutorial.pdf) talks about defining GUI classes using swing, but then gives an example in which no GUI classes are defined. Instead it seems to be using the TestBean framework, which I can't find much information on but apparently takes the properties of a class an generates a GUI from them for you. I can see samplers in the source code that use both methods (the TestAction sampler defined its own GUI whereas the DebuggerSampler uses the TestBean method). Is one method preferred over the other or do you use TestBean unless you need more control over the GUI in which case you define your own? Sorry if these are basic questions, but I'm having trouble finding much documentation related to extending the system. On Thu, Jun 16, 2011 at 4:53 PM, Bruce Ide flyingrhenqu...@gmail.comwrote: You just roll 'em up in a Jar file. I use maven for my builds and it puts a jar together for me. As long as you implemented the interfaces correctly and conform to (what I assume are) the bean standards, jmeter just picks your object up and you get new menu entries in the correct locations and everything. If you did something wrong, you either don't get a new menu entry for your sampler, or you get one but it has the wrong label, or no label. Or it looks like it's going to work but you can't actually configure the sampler. It's a good idea to pull in the logging classes earlier rather than later, and log everything. Then you can look in your jmeter log and see how far your class got, or if it get anywhere at all. -- Bruce Ide flyingrhenqu...@gmail.com
Custom Sampler Tutorial
I'm new to JMeter and am looking for a tutorial on how to write a customer sampler. I would think this would be a popular topic, but I'm not really finding much on it. I've seen this document http://jakarta.apache.org/jmeter/extending/jmeter_tutorial.pdf and didn't find it terribly helpful. Am I missing something here? Why aren't there tons of examples on how to do this?
Output by number of users
I have a question about JMeter output, particularly graphs and tables. Most of the data contained in the listeners gives data over time. That's useful information, but in addition to that I really would like to see how that information changes as the load increases. So something like request time on the y axis and number of concurrent users on the x axis would be an example. Does the system support this out of the box? As a reference, you can look at the output of another load test tool called FunkLoad here: http://funkload.nuxeo.org/report-example/test_seam_java6/ I realize I could probably run multiple rounds of tests, cranking up the number of users each time then merging all the data together and somehow making a graph out of it (maybe Excel), but I was hoping for something built in. Thanks, Dave
Re: Output by number of users
Wow, thanks. That's exactly what I was thinking. Not to mention all the other sweet visualizations provided by that plugin. Very nice. On Mon, Jun 13, 2011 at 3:34 PM, apc a...@apc.kg wrote: Hi, Check out this graph: http://code.google.com/p/jmeter-plugins/wiki/ResponseTimesVsThreads -- View this message in context: http://jmeter.512774.n5.nabble.com/Output-by-number-of-users-tp4485598p4485629.html Sent from the JMeter - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
Re: Concurrent HTTP requests to simulate AJAX client
I'm thinking I'm probably going to have to write my own sampler for this. The reason being that the requests can't be for random tiles from anywhere on the map, they have to be based on what would actually be requested if the user were to pan around or zoom in and out. This is because we are putting certain optimizations in place based on tile locality. I don't know that the CSV Dataset element will provide me with enough control in terms of which threads get which requests (though I'm not sure since I have pretty much zero experience with it). I would like each thread to work at a different location in the map so no two threads requests the same tile. This is so I can take the cache we have in place out of the equation (for now). That's probably going to require some configuration and management at a higher level somehow. Perhaps the CSV Dataset could aid in this aspect. Dave On Mon, Jun 13, 2011 at 1:31 PM, Bruce Ide flyingrhenqu...@gmail.comwrote: You could drop all the URLs you want to request into a CSV file. In your thread group you'd set the number of users to however many threads you want to use for your requests. The CSV data element can parcel the requests out between threads (it loads them into variables that are unique in each thread) and then you could make the requests simultaneously. As long as you use the variable from the CSV element as the URL for your request, that should work pretty well with a single thread group doing the work. For just stress-testing tile-getting, that's pretty easy. If you want it to do anything else while requesting tiles, or if you want it to start requesting tiles at one point in the test, and then stop later on (While still doing other stuff,) that could get more complicated. -- Bruce Ide flyingrhenqu...@gmail.com
Concurrent HTTP requests to simulate AJAX client
I have a fairly basic question about how well JMeter will support and AJAX-based client. I am trying to load test an application in which the user views a map in the browser. As they navigate around or zoom in and out, the browser makes AJAX REST calls to a server to download the required image blocks of the map (like google maps). Most browsers support making 4 or 5 simultaneous http requests. So to properly simulate a bunch of browsers hitting the server all at once, I need each worker thread (the thread being the browser) to support sending out batches of 4 or 5 requests at the same time. How well will JMeter support this? Will I have to spin off and manage my own threads within the worker threads or does JMeter provide any help with this? Will JMeter be able to track statistics for each individual thread inside each worker thread? Thanks, Dave
