date:20110914

Re: How to pass a parameter to internal request (embedded)

2011-09-14 Thread Oliver Lloyd

The referer is not the request, it is from where the request was referred.

-
http://www.http503.com/
--
View this message in context: 
http://jmeter.512774.n5.nabble.com/How-to-pass-a-parameter-to-internal-request-embedded-tp4800759p4801913.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

2011-09-14 Thread sebb

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

Re: About Constant Timer / Constant Throughtput Timer

2011-09-14 Thread Shmuel Krakower

I wasn't familiar with the Throughput Shaping Timer, it seems like what we
need.
The only drawback of this solution is that we have some extra threads
waiting to be executed.

I will give it a try soon and probably will use it often.


On Tue, Sep 13, 2011 at 9:44 PM, Deepak Shetty shet...@gmail.com wrote:

 You shouldnt use  Constant timer for such requirements , because that would
 need you to know in advance the average time your request responds in - for
 you to be able to calculate the delay you need to get the rate of requests
 you want

 These type of requirements are met by the constant throughput timer (or by
 the throughput shaping timer from jmeter-plugins
 http://code.google.com/p/jmeter-plugins/wiki/ThroughputShapingTimer).

 So you should be able to say 144000 samples per minute and all threads -
 because thats what you want. If you want to calculate it per thread then
 you
 might be off by a little because they may not all respond the same
 (Especially if you have synchronization problems). Youll have to divide
 your
 wanted number by the number of threads and then specify the value.

 However if you look at the Number of threads you have = 80 , and you want
 2400 requests per second , it means each thread must be able to make 30
 requests in a second - which means your requests on average should be about
 1000(milliseconds)/30 = 33 milliseconds (assuming Jmeter takes no time ,
 which is invalid when you are dealing with small values and youll have to
 factor this in). Depending on what your java request does , such an
 assumption may not be correct and you have to increase your number of
 threads. however you cannot also keep on increasing the number of threads
 for a single jvm instance (if you see that your throughput doesnt increase
 with the number of threads and doesnt reach the value you want - you have
 to
 either tune jmeter or tune your app - or distribute Jmeter but that might
 be
 problematic depending on what he java sampler does)

 You usually run your test for a long enough duration so that ramp up or
 down
 is not signifcant. (there's a recent thread in the archives that discusses
 this)

 http://code.google.com/p/jmeter-plugins/wiki/ThroughputShapingTimer also
 has
 some information


 regards
 deepak

 On Sun, Sep 11, 2011 at 11:22 PM, Raghavendra Kristam
 raghala...@yahoo.comwrote:

  Hi,
 
  I am using JMeter(2.4) for doing the loading testing of XMPP server and
 my
  test plan is configured as following:
 
  - Test plan
- Thread group
  - Loop Controller
  - Java Request
 - Generate Summary Results
 - Constant timer/Constant throughput timer
   - CSV Data Set Config
   - CSV Data Set Config
   - CSV Data Set Config
  For example :
  Number of Threads: 80
  Ramp up period: 80
  Duration: 1800 secs
  a) If I use constant timer = 1000 milli secs then the output as follows:
  Number of samples/Throughput/Avg/Error = 129307 / 71.2/sec / 64 milli
  secs / 0.00%
  b) If I use constant throughput timer, target throughput (in samples per
  minute): 100 and Calculate throughput based on: this thread only then the
  output as follows:
  Number of samples/Throughput/Avg/Error = 214372 / 119.6/sec / 72
 milli
  secs / 12.7%
 
  I need to configure the test plan to get the throughput as around 2400
  samples per sec (144000 /min 864/hr).
 
  Please suggest me what timer should I use
 
  How do I calculate the number of threads / rampup period / constant timer
  values for this.
 
 
  Thanks
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
  For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org

While Controller | Reverse Logic?

2011-09-14 Thread Oliver Lloyd

Is it possible to reverse the logic in the while controller?

So, I have this:

ThreadGroup
---Sampler | This returns foo
--Regexp   | My regexp is bar (thus = false)
---While | ${__javaScript(${FOO_VAR})}
--Sampler  | This returns foobar
-Regexp   | My regexp is bar (thus = true)

Basically, I want the test to poll a request until it sees 'bar' and then,
at that point, it should exit the loop. My problem is the regexp returns
'false' when it does NOT find the text so in the example above the logic is
reversed.

Before I start hacking up a messy workaround I wanted to see if there were a
more elegant solution; I feel like I am missing a '!' in the right place...

-
http://www.http503.com/
--
View this message in context: 
http://jmeter.512774.n5.nabble.com/While-Controller-Reverse-Logic-tp4802300p4802300.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: While Controller | Reverse Logic?

2011-09-14 Thread sebb

On 14 September 2011 11:42, Oliver Lloyd oliver_ll...@hotmail.com wrote:
 Is it possible to reverse the logic in the while controller?

 So, I have this:

 ThreadGroup
 ---Sampler         | This returns foo
 --Regexp       | My regexp is bar (thus = false)
 ---While             | ${__javaScript(${FOO_VAR})}
 --Sampler      | This returns foobar
 -Regexp   | My regexp is bar (thus = true)

 Basically, I want the test to poll a request until it sees 'bar' and then,
 at that point, it should exit the loop. My problem is the regexp returns
 'false' when it does NOT find the text so in the example above the logic is
 reversed.

I assume the regex default value is 'false' ?

 Before I start hacking up a messy workaround I wanted to see if there were a
 more elegant solution; I feel like I am missing a '!' in the right place...

It's very tricky using a regex to not match a subsequence of a string.

I suspect the easiest solution is to change the while condition to
compare the regex var against the desired value, rather than relying
on the regex returning false.

 -
 http://www.http503.com/
 --
 View this message in context: 
 http://jmeter.512774.n5.nabble.com/While-Controller-Reverse-Logic-tp4802300p4802300.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

Re: While Controller | Reverse Logic?

2011-09-14 Thread Oliver Lloyd

Yes, regex defaults to false. But actually, what you suggest is perfect,
thanks. For some reason I had the impression that a comparison was not
possible as the condition but it is completely logical that you should be
able to do this, it's even right there in the help.

So, for the thread (although this is actually pretty obvious in the end) a
condition of ${__javaScript(${FOO_VAR}==false)} gives me what I need.

-
http://www.http503.com/
--
View this message in context: 
http://jmeter.512774.n5.nabble.com/While-Controller-Reverse-Logic-tp4802300p4802708.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

Startup Cost on first operation

2011-09-14 Thread Nicholson, Brad (Toronto, ON, CA)

Hi,

I am using jmeter 2.5 and I am triggering my test via Ant and using the Jenkins 
Performance Plugin to display the data.

With each test I run, the first result has heavily inflated times (hundreds of 
milliseconds instead of a few).  I'd like to avoid having such high numbers in 
the initial operation.  Google seems to imply that this is paying the 
complication time of the jmeter script during this operation. 

I can absorb the cost of this operation by adding a dummy operation at the 
start of the test, but I am wondering if there is a simpler/cleaner way of 
doing this?
 
Thanks,
Brad. 

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

Issue with Response assertion for HTTP Request Sampler

2011-09-14 Thread Karthik110885

Hi All,

I am a newbie so please tolerate with my ignorance :)

I have installed JMeter 2.5 version and have configured HTTP Request sampler
to send a request. I receive the response successfully without any issues.
Now, i have to verify that the response contains a particular block of xml
(multiple lines) to make sure that i have received the proper response. So i
have added response assertion to the HTTP Request sampler and copied the
block of xml to it

Now, When i send HTTP request to a server in non-windows platform everything
works fine. But when i send the same request to a server in windows
platform, the response assertion fails even though the response contains the
block of xml verified through response assertion. But if i give a one line
text or one line xml from the block of xml in response assertion it is
passed.

Please let me know if i am doing anything wrong. Is multiple line comparison
allowed in response assertion?

Thanks in advance.

--
View this message in context: 
http://jmeter.512774.n5.nabble.com/Issue-with-Response-assertion-for-HTTP-Request-Sampler-tp4803205p4803205.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: Issue with Response assertion for HTTP Request Sampler

2011-09-14 Thread sebb

On 14 September 2011 16:16, Karthik110885 karthik110...@gmail.com wrote:
 Hi All,

 I am a newbie so please tolerate with my ignorance :)

 I have installed JMeter 2.5 version and have configured HTTP Request sampler
 to send a request. I receive the response successfully without any issues.
 Now, i have to verify that the response contains a particular block of xml
 (multiple lines) to make sure that i have received the proper response. So i
 have added response assertion to the HTTP Request sampler and copied the
 block of xml to it

 Now, When i send HTTP request to a server in non-windows platform everything
 works fine. But when i send the same request to a server in windows
 platform, the response assertion fails even though the response contains the
 block of xml verified through response assertion. But if i give a one line
 text or one line xml from the block of xml in response assertion it is
 passed.

 Please let me know if i am doing anything wrong. Is multiple line comparison
 allowed in response assertion?

That sounds like an issue with end-of-line matching.

I would expect the response to not vary between OSes, but perhaps the
regex processing might.

You can save the input XML using this Listener:

http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Save_Responses_to_a_file

and make sure they are the same on both OSes.

If so, then it must be an issue with the way the regex is defined or processed.

 Thanks in advance.

 --
 View this message in context: 
 http://jmeter.512774.n5.nabble.com/Issue-with-Response-assertion-for-HTTP-Request-Sampler-tp4803205p4803205.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

Re: Startup Cost on first operation

2011-09-14 Thread sebb

On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
bnichol...@hp.com wrote:
 Hi,

 I am using jmeter 2.5 and I am triggering my test via Ant and using the 
 Jenkins Performance Plugin to display the data.

 With each test I run, the first result has heavily inflated times (hundreds 
 of milliseconds instead of a few).  I'd like to avoid having such high 
 numbers in the initial operation.  Google seems to imply that this is paying 
 the complication time of the jmeter script during this operation.

Do you mean compilation time?

If so, that is done before the sample is started; sample times include
only the time needed to perform the sample.

 I can absorb the cost of this operation by adding a dummy operation at the 
 start of the test, but I am wondering if there is a simpler/cleaner way of 
 doing this?

That should not be necessary; there must be something else happening here.

Try using a Java sampler. Does the first sample take longer than the next?
What happens if you add a dummy before that?

Are you sure that the Jenkins Performance plugin is measuring samples,
and not JMeter startup time?

 Thanks,
 Brad.

 -
 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

2011-09-14 Thread E S

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: Startup Cost on first operation

2011-09-14 Thread Nicholson, Brad (Toronto, ON, CA)

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: Wednesday, September 14, 2011 11:27 AM
 To: JMeter Users List
 Subject: Re: Startup Cost on first operation

 On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
 bnichol...@hp.com wrote:
  Hi,

  I am using jmeter 2.5 and I am triggering my test via Ant and using
 the Jenkins Performance Plugin to display the data.

  With each test I run, the first result has heavily inflated times
 (hundreds of milliseconds instead of a few).  I'd like to avoid having
 such high numbers in the initial operation.  Google seems to imply that
 this is paying the complication time of the jmeter script during this
 operation.

 Do you mean compilation time?

Sorry, yes - I mean compilation time.

 If so, that is done before the sample is started; sample times include
 only the time needed to perform the sample.

  I can absorb the cost of this operation by adding a dummy operation
 at the start of the test, but I am wondering if there is a
 simpler/cleaner way of doing this?

 That should not be necessary; there must be something else happening
 here.

 Try using a Java sampler. Does the first sample take longer than the
 next?

No - they are fairly uniform

 What happens if you add a dummy before that?

Dummy request takes a higher startup time, no change the Java request.

All my requests (including the dummy request) are HTTP Request's and are 
connecting via https. 

 Are you sure that the Jenkins Performance plugin is measuring samples,
 and not JMeter startup time?

I'm sure it's not.  I've confirmed by checking the raw output files written by 
Jmeter.  To completely eliminate other moving pieces, I've re-run the test 
repeatedly directly from Jmeter and I see the same behavior.

Brad.

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

Re: Startup Cost on first operation

2011-09-14 Thread sebb

On 14 September 2011 17:57, Nicholson, Brad (Toronto, ON, CA)
bnichol...@hp.com wrote:
 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: Wednesday, September 14, 2011 11:27 AM
 To: JMeter Users List
 Subject: Re: Startup Cost on first operation

 On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
 bnichol...@hp.com wrote:
  Hi,

  I am using jmeter 2.5 and I am triggering my test via Ant and using
 the Jenkins Performance Plugin to display the data.

  With each test I run, the first result has heavily inflated times
 (hundreds of milliseconds instead of a few).  I'd like to avoid having
 such high numbers in the initial operation.  Google seems to imply that
 this is paying the complication time of the jmeter script during this
 operation.

 Do you mean compilation time?

 Sorry, yes - I mean compilation time.

 If so, that is done before the sample is started; sample times include
 only the time needed to perform the sample.

  I can absorb the cost of this operation by adding a dummy operation
 at the start of the test, but I am wondering if there is a
 simpler/cleaner way of doing this?

 That should not be necessary; there must be something else happening
 here.

 Try using a Java sampler. Does the first sample take longer than the
 next?

 No - they are fairly uniform

 What happens if you add a dummy before that?

 Dummy request takes a higher startup time, no change the Java request.

 All my requests (including the dummy request) are HTTP Request's and are 
 connecting via https.

https is much more expensive in connection setup

 Are you sure that the Jenkins Performance plugin is measuring samples,
 and not JMeter startup time?

 I'm sure it's not.  I've confirmed by checking the raw output files written 
 by Jmeter.  To completely eliminate other moving pieces, I've re-run the test 
 repeatedly directly from Jmeter and I see the same behavior.

The only thing I can think of that might be causing the problem is the
connection setup.
First time JMeter init for a connection will be slightly slower, but
should barely be noticeable; it will be the external stuff that takes
the most time.
And that will apply to browsers as well.

Does the additional time apply to other target hosts?

Which sampler are you using?

Are you using Keep-Alive?
If you switch it off, each sampler will have to create the connection
anew, so I would expect all the samples to take longer.

AFAIK, JMeter itself does not do any expensive first-time init for
either https or http (obviously if it does that should be fixed to
exclude that time).
However connections do have a setup overhead, which will apply to any
application, including browsers, and need to be included in the JMeter
sample time.

 Brad.

 -
 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

2011-09-14 Thread sebb

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:

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

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?

-
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

2011-09-14 Thread E S

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:

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?

-
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

2011-09-14 Thread E S

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

2011-09-14 Thread Deepak Shetty

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:

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

RE: Startup Cost on first operation

2011-09-14 Thread Nicholson, Brad (Toronto, ON, CA)

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: Wednesday, September 14, 2011 1:29 PM
 To: JMeter Users List
 Subject: Re: Startup Cost on first operation

 On 14 September 2011 17:57, Nicholson, Brad (Toronto, ON, CA)
 bnichol...@hp.com wrote:
  -Original Message-
  From: sebb [mailto:seb...@gmail.com]
  Sent: Wednesday, September 14, 2011 11:27 AM
  To: JMeter Users List
  Subject: Re: Startup Cost on first operation

  On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
  bnichol...@hp.com wrote:
   Hi,

   I am using jmeter 2.5 and I am triggering my test via Ant and
 using
  the Jenkins Performance Plugin to display the data.

   With each test I run, the first result has heavily inflated times
  (hundreds of milliseconds instead of a few).  I'd like to avoid
 having
  such high numbers in the initial operation.  Google seems to imply
 that
  this is paying the complication time of the jmeter script during
 this
  operation.

  Do you mean compilation time?

  Sorry, yes - I mean compilation time.

  If so, that is done before the sample is started; sample times
 include
  only the time needed to perform the sample.

   I can absorb the cost of this operation by adding a dummy
 operation
  at the start of the test, but I am wondering if there is a
  simpler/cleaner way of doing this?

  That should not be necessary; there must be something else happening
  here.

  Try using a Java sampler. Does the first sample take longer than the
  next?

  No - they are fairly uniform

  What happens if you add a dummy before that?

  Dummy request takes a higher startup time, no change the Java
 request.

  All my requests (including the dummy request) are HTTP Request's and
 are connecting via https.

 https is much more expensive in connection setup

  Are you sure that the Jenkins Performance plugin is measuring
 samples,
  and not JMeter startup time?

  I'm sure it's not.  I've confirmed by checking the raw output files
 written by Jmeter.  To completely eliminate other moving pieces, I've
 re-run the test repeatedly directly from Jmeter and I see the same
 behavior.

 The only thing I can think of that might be causing the problem is the
 connection setup.
 First time JMeter init for a connection will be slightly slower, but
 should barely be noticeable; it will be the external stuff that takes
 the most time.
 And that will apply to browsers as well.

 Does the additional time apply to other target hosts?

Yes - I've run it against a number of different hosts and the first request is 
always significantly higher.

 Which sampler are you using?

HTTP Request

 Are you using Keep-Alive?

Yes

 If you switch it off, each sampler will have to create the connection
 anew, so I would expect all the samples to take longer.

I tried with keep alive off and there is no statistically interesting 
difference.  First operation is always around 600ms, all subsequent run between 
8ms to 25ms.  It's the same for both keep-alive enabled and disabled.  I've 
tested with a variety of URL's btw, and the result is always the same.

 AFAIK, JMeter itself does not do any expensive first-time init for
 either https or http (obviously if it does that should be fixed to
 exclude that time).
 However connections do have a setup overhead, which will apply to any
 application, including browsers, and need to be included in the JMeter
 sample time.

There seems to be something in Jmeter causing this.  I tried testing some of 
the same URL's with Apache Benchmark and I pay no startup cost on those tests.

Brad.

-
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

2011-09-14 Thread E S

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