You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Christiaan Lamprecht <ch...@googlemail.com> on 2007/10/26 19:58:02 UTC
Duration assertion
Hi,
I'm having some trouble with the Duration Assertion. I also enabled
httpclient.timeout in the jmeter.properties file. The problem is that
when it's enabled, the logs show that the number of bytes received per
request is 1815 instead of 44 (44 is the size of the file requested)
and this seems to then take up all the bandwidth. Any idea what it
could be? Test plan and some results are below:
10 clients, 10 JMeter instances, each running:
Test Plan
Thread Group (users 100, ramp 100, count 250)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
Duration assertion (99)
Uniform Random Timer (Offset 100, dev 10)
httpclient.timeout=99
TimeStamp,elapsed,bytes,latency
....................................
1193419432792,80,44,80
1193419432899,11,44,11
1193419432901,13,44,13
1193419432907,11,44,11
1193419432903,25,44,25
1193419432947,11,44,11
1193419432951,11,44,11
1193419433015,11,44,11
1193419433023,11,44,11
1193419433031,11,44,11
1193419433047,11,44,11
1193419433071,10,44,10
1193419433072,12,44,12
1193419433135,11,44,11
1193419433171,10,44,10
1193419433195,10,44,10
1193419433196,12,44,12
1193419433287,10,44,10
1193419433415,10,44,10
1193419433535,10,44,10
1193419433655,10,44,10
1193419433775,10,44,10
1193419412622,21218,1815,0
1193419432657,3219,1815,0
1193419435991,213,1815,0
1193419436079,217,1815,0
1193419433959,3209,1815,0
1193419434627,3217,1815,0
1193419437952,212,1815,0
1193419435075,3217,1815,0
1193419438404,212,1815,0
1193419438672,216,1815,0
1193419438732,212,1815,0
1193419439008,212,1815,0
1193419439060,212,1815,0
1193419439696,216,1815,0
1193419431124,9212,1815,0
...
...
...
Thanks for any help in advance
Christiaan
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Duration assertion
Posted by sebb <se...@gmail.com>.
On 05/11/2007, Christiaan Lamprecht <ch...@googlemail.com> wrote:
> > Only if the server can cope with the load. If the server is slow in
> > responding, then the JMeter threads will be slowed down also.
> >
> > This is how request-response protocols work - the thread cannot
> > proceed with another request until the previous response has arrived.
>
> I see, so new requests are made when a response is received unless
> they're part of a newly created thread in which case there's no
> previous request to wait for;
Each thread operates independently. Once a thread has sent a request,
it waits for a response (or timeout, if appropriate) before
proceeding.
> So in the example below (if the server
> is busy) requests within each thread will wait for a response before
> sending a new request but a new thread will be created (and make a
> request) every second (for 100 seconds) regardless of how busy the
> server is;
>
> Test Plan (Run each Thread group separately)
> Thread Group (users 100, ramp 100, count 20)
> HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> Uniform Random Timer (Offset 100, dev 10)
Yes. The timer will add a small variance - the first sample in each
thread will start approx. 1 second after the previous one.
> > Also, if you want to maintain a constant load, then you should
> > consider using the Constant Throughput timer. This adjusts the waits
> > according to the current rate. But of course it won't be able to
> > maintain a throughput greater than that supported by the server or the
> > the JMeter host.
>
> I've been trying this but not sure if I'm taking the right approach. I
> want to simulate a constant throughput with new users arriving/leaving
> throughout the experiment;
>
> Test Plan (Duration 100)
> Thread Group (users 100, ramp 100, count Forever)
> HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> Constant Throughput Timer (120 req/m)
>
> So the above testplan means this; After 1 second there will be one
> user doing 120req/m and after 100 seconds there will be 100 users
> sharing that responsibility each doing a fraction of the 120req/m
Depends which "Calculate Throughput based on" option is selected, see:
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Constant_Throughput_Timer
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Duration assertion
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
> Only if the server can cope with the load. If the server is slow in
> responding, then the JMeter threads will be slowed down also.
>
> This is how request-response protocols work - the thread cannot
> proceed with another request until the previous response has arrived.
I see, so new requests are made when a response is received unless
they're part of a newly created thread in which case there's no
previous request to wait for; So in the example below (if the server
is busy) requests within each thread will wait for a response before
sending a new request but a new thread will be created (and make a
request) every second (for 100 seconds) regardless of how busy the
server is;
Test Plan (Run each Thread group separately)
Thread Group (users 100, ramp 100, count 20)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
Uniform Random Timer (Offset 100, dev 10)
> Also, if you want to maintain a constant load, then you should
> consider using the Constant Throughput timer. This adjusts the waits
> according to the current rate. But of course it won't be able to
> maintain a throughput greater than that supported by the server or the
> the JMeter host.
I've been trying this but not sure if I'm taking the right approach. I
want to simulate a constant throughput with new users arriving/leaving
throughout the experiment;
Test Plan (Duration 100)
Thread Group (users 100, ramp 100, count Forever)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
Constant Throughput Timer (120 req/m)
So the above testplan means this; After 1 second there will be one
user doing 120req/m and after 100 seconds there will be 100 users
sharing that responsibility each doing a fraction of the 120req/m
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Duration assertion
Posted by sebb <se...@gmail.com>.
On 29/10/2007, Christiaan Lamprecht <ch...@googlemail.com> wrote:
> > > All requests finish ok but I want to enable timeouts as the client
> > > seems to wait for the server before sending more requests. Example:
> >
> > Each user (thread) will wait for a response before sending the next request.
> >
> > Is that what you are referring to, or are you saying that all threads
> > in the JMeter client sometimes wait?
>
> I mean that waiting takes precedence over sending more requests.
But what is waiting here?
Each thread will wait for a response before sending the next request -
is that what you mean?
> Perhaps an example would be easier:
>
> Test Plan (Run each Thread group separately)
> Thread Group (users 1, ramp 1, count 20)
> HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> Uniform Random Timer (Offset 100, dev 10)
>
> If the server is busy the 20 requests in the above testplan will not
> be made 100ms apart. (i.e the request rate will be much lower than 10
> req/s) I understand that each request has to wait for the server but
> the requests seem to wait for each other and so the request rate is
> much less than 10 req/s
>
What do you mean by "requests seem to wait for each other" ?
If you mean that a single thread waits for a response before sending
the next request, then yes, that is how a request-response protocol
works.
If you mean that one thread waits for a response in a different thread
before sending its request, then please explain what data leads you to
that conclusion.
> > > Test Plan (Run each Thread group separately)
> > > Thread Group (users 100, ramp 100, count 20)
> > > HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> > > Thread Group (users 100, ramp 100, count 30)
> > > HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> > > Thread Group (users 100, ramp 100, count 40)
> > > HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> > > ...
> > > ...
> > > ...
> > > Thread Group (users 100, ramp 100, count 310)
> > > HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> > > Uniform Random Timer (Offset 100, dev 10)
> > >
> > >
> > > Results for 10 clients (each running a JMeter instance):
> > >
> > > Requested request rate, Average time between requests, Actual
> > > (average) request rate
> > > 200 6.59422971 151.6477351
> > > 300 4.348678 229.9549426
> > > 400 3.276406 305.2124798
> > > 500 2.655733 376.543877
> > > 600 2.233653 447.6971132
> > > 700 1.90895 523.8481888
> > > 800 1.66188 601.7281633
> > > 900 1.465338 682.4364072
> > > 1000 1.3544235 738.3215073
> > > 1300 1.176124 850.2504838
> > > 1600 1.139619 877.4862476
> > > 1900 1.07916883 926.6390691
> > > 2200 1.008209 991.857839
> > > 2500 1.0388161 962.6342911
> > > 2800 0.97919992 1021.241914
> > > 3100 1.04185174 959.8294667
> > >
> > > As you can see the actual request rate converges at 1000 req/s. To
> > > check if this (100 req/s per client) is a client machine limitation I
> > > ran the testplan against the server using only one client:
> > >
> > > 20 51.92796398 19.25744673
> > > 30 34.40246749 29.06768244
> > > 40 26.11477869 38.29249375
> > > 50 21.1030206 47.38658124
> > > 60 17.75179196 56.33234111
> > > 70 15.39391341 64.96073957
> > > 80 13.61495186 73.4486622
> > > 90 12.24736081 81.65024412
> > > 100 11.10651065 90.03727917
> > > 130 8.86183552 112.8434395
> > > 160 7.44715294 134.2795036
> > > 190 6.474603926 154.4496021
> > > 220 5.739533615 174.2301844
> > > 250 5.2158886 191.7218861
> > > 280 4.76088431 210.0450116
> > > 310 4.456917965 224.3702953
> > >
> > > Clearly more than 100 req/s is achieved. So the client does not seem
> > > to be the bottleneck.
> > >
> > >
> > >
> > > So why does the client wait before sending more requests?:
> >
> > What do you mean by this? What evidence is there?
>
> For the 10 client experiment you would expect the last thread group...
> ....
> ....
> Thread Group (users 100, ramp 100, count 310)
> HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> Uniform Random Timer (Offset 100, dev 10)
>
> ... to maintain about 3100 req/s almost throughout the 100 seconds
> that it runs but it only does 959.8... and the results above show that
> none of the Thread Groups manage more than about 1000 req/s (Which is
> about 100 req/s per machine)
Only if the server can cope with the load. If the server is slow in
responding, then the JMeter threads will be slowed down also.
This is how request-response protocols work - the thread cannot
proceed with another request until the previous response has arrived.
Also, if you want to maintain a constant load, then you should
consider using the Constant Throughput timer. This adjusts the waits
according to the current rate. But of course it won't be able to
maintain a throughput greater than that supported by the server or the
the JMeter host.
> > > Since SSL is done transparently, perhaps without knowing JMeter has to
> > > wait for the SSL session to be established, which will take longer if
> > > the server is busy, and so it's unknowingly 'busy' doing that instead
> > > of making new requests..?
> > >
> >
> > Which version of JMeter are you using?
>
> jakarta-jmeter-2.3RC4
The current version is 2.3.
I don't think there are any fixes relevant to your particular testing,
but it would be sensible to update to 2.3.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Duration assertion
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
> > All requests finish ok but I want to enable timeouts as the client
> > seems to wait for the server before sending more requests. Example:
>
> Each user (thread) will wait for a response before sending the next request.
>
> Is that what you are referring to, or are you saying that all threads
> in the JMeter client sometimes wait?
I mean that waiting takes precedence over sending more requests.
Perhaps an example would be easier:
Test Plan (Run each Thread group separately)
Thread Group (users 1, ramp 1, count 20)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
Uniform Random Timer (Offset 100, dev 10)
If the server is busy the 20 requests in the above testplan will not
be made 100ms apart. (i.e the request rate will be much lower than 10
req/s) I understand that each request has to wait for the server but
the requests seem to wait for each other and so the request rate is
much less than 10 req/s
> > Test Plan (Run each Thread group separately)
> > Thread Group (users 100, ramp 100, count 20)
> > HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> > Thread Group (users 100, ramp 100, count 30)
> > HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> > Thread Group (users 100, ramp 100, count 40)
> > HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> > ...
> > ...
> > ...
> > Thread Group (users 100, ramp 100, count 310)
> > HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> > Uniform Random Timer (Offset 100, dev 10)
> >
> >
> > Results for 10 clients (each running a JMeter instance):
> >
> > Requested request rate, Average time between requests, Actual
> > (average) request rate
> > 200 6.59422971 151.6477351
> > 300 4.348678 229.9549426
> > 400 3.276406 305.2124798
> > 500 2.655733 376.543877
> > 600 2.233653 447.6971132
> > 700 1.90895 523.8481888
> > 800 1.66188 601.7281633
> > 900 1.465338 682.4364072
> > 1000 1.3544235 738.3215073
> > 1300 1.176124 850.2504838
> > 1600 1.139619 877.4862476
> > 1900 1.07916883 926.6390691
> > 2200 1.008209 991.857839
> > 2500 1.0388161 962.6342911
> > 2800 0.97919992 1021.241914
> > 3100 1.04185174 959.8294667
> >
> > As you can see the actual request rate converges at 1000 req/s. To
> > check if this (100 req/s per client) is a client machine limitation I
> > ran the testplan against the server using only one client:
> >
> > 20 51.92796398 19.25744673
> > 30 34.40246749 29.06768244
> > 40 26.11477869 38.29249375
> > 50 21.1030206 47.38658124
> > 60 17.75179196 56.33234111
> > 70 15.39391341 64.96073957
> > 80 13.61495186 73.4486622
> > 90 12.24736081 81.65024412
> > 100 11.10651065 90.03727917
> > 130 8.86183552 112.8434395
> > 160 7.44715294 134.2795036
> > 190 6.474603926 154.4496021
> > 220 5.739533615 174.2301844
> > 250 5.2158886 191.7218861
> > 280 4.76088431 210.0450116
> > 310 4.456917965 224.3702953
> >
> > Clearly more than 100 req/s is achieved. So the client does not seem
> > to be the bottleneck.
> >
> >
> >
> > So why does the client wait before sending more requests?:
>
> What do you mean by this? What evidence is there?
For the 10 client experiment you would expect the last thread group...
....
....
Thread Group (users 100, ramp 100, count 310)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
Uniform Random Timer (Offset 100, dev 10)
... to maintain about 3100 req/s almost throughout the 100 seconds
that it runs but it only does 959.8... and the results above show that
none of the Thread Groups manage more than about 1000 req/s (Which is
about 100 req/s per machine)
> > Since SSL is done transparently, perhaps without knowing JMeter has to
> > wait for the SSL session to be established, which will take longer if
> > the server is busy, and so it's unknowingly 'busy' doing that instead
> > of making new requests..?
> >
>
> Which version of JMeter are you using?
jakarta-jmeter-2.3RC4
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Duration assertion
Posted by sebb <se...@gmail.com>.
On 27/10/2007, Christiaan Lamprecht <ch...@googlemail.com> wrote:
> > I don't understand why enabling timeouts should increase the run-time
> > - it might decrease, but should not increase.
> >
> > If you don't use timeouts, do all the requests finish OK, or do some hang?
> >
> > I'm not clear why you wanted to enable timeouts...
>
> All requests finish ok but I want to enable timeouts as the client
> seems to wait for the server before sending more requests. Example:
Each user (thread) will wait for a response before sending the next request.
Is that what you are referring to, or are you saying that all threads
in the JMeter client sometimes wait?
> Test Plan (Run each Thread group separately)
> Thread Group (users 100, ramp 100, count 20)
> HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> Thread Group (users 100, ramp 100, count 30)
> HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> Thread Group (users 100, ramp 100, count 40)
> HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> ...
> ...
> ...
> Thread Group (users 100, ramp 100, count 310)
> HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> Uniform Random Timer (Offset 100, dev 10)
>
>
> Results for 10 clients (each running a JMeter instance):
>
> Requested request rate, Average time between requests, Actual
> (average) request rate
> 200 6.59422971 151.6477351
> 300 4.348678 229.9549426
> 400 3.276406 305.2124798
> 500 2.655733 376.543877
> 600 2.233653 447.6971132
> 700 1.90895 523.8481888
> 800 1.66188 601.7281633
> 900 1.465338 682.4364072
> 1000 1.3544235 738.3215073
> 1300 1.176124 850.2504838
> 1600 1.139619 877.4862476
> 1900 1.07916883 926.6390691
> 2200 1.008209 991.857839
> 2500 1.0388161 962.6342911
> 2800 0.97919992 1021.241914
> 3100 1.04185174 959.8294667
>
> As you can see the actual request rate converges at 1000 req/s. To
> check if this (100 req/s per client) is a client machine limitation I
> ran the testplan against the server using only one client:
>
> 20 51.92796398 19.25744673
> 30 34.40246749 29.06768244
> 40 26.11477869 38.29249375
> 50 21.1030206 47.38658124
> 60 17.75179196 56.33234111
> 70 15.39391341 64.96073957
> 80 13.61495186 73.4486622
> 90 12.24736081 81.65024412
> 100 11.10651065 90.03727917
> 130 8.86183552 112.8434395
> 160 7.44715294 134.2795036
> 190 6.474603926 154.4496021
> 220 5.739533615 174.2301844
> 250 5.2158886 191.7218861
> 280 4.76088431 210.0450116
> 310 4.456917965 224.3702953
>
> Clearly more than 100 req/s is achieved. So the client does not seem
> to be the bottleneck.
>
>
>
> So why does the client wait before sending more requests?:
What do you mean by this? What evidence is there?
> Since SSL is done transparently, perhaps without knowing JMeter has to
> wait for the SSL session to be established, which will take longer if
> the server is busy, and so it's unknowingly 'busy' doing that instead
> of making new requests..?
>
Which version of JMeter are you using?
> > > 1193316042700,32,HTTP Request HTTPClient,200,OK,Thread Group
> > > 1-1,text,true,,44,7,7,https://cala01.ac.uk:8083/index.html,,32,ISO-8859-1
> > >
> > >
> > > 1193316042484,203,HTTP Request HTTPClient,Non HTTP response code:
> > > java.net.SocketTimeoutException,Non HTTP response message: Read timed
> > > out,Thread Group
> > > 1-4,text,false,,1815,7,7,https://cala01.ac.uk:8083/index.html,,0,ISO-8859-1
> >
> > This shows that the longer elapsed time is associated with the
> > timeout; I assume all the longer responses are also timeouts?
>
> Not all but the vast majority of the longer elapsed times are timeouts.
>
>
> Thanks for all the help, I'm really stuck on this one
> Christiaan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Duration assertion
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
> I don't understand why enabling timeouts should increase the run-time
> - it might decrease, but should not increase.
>
> If you don't use timeouts, do all the requests finish OK, or do some hang?
>
> I'm not clear why you wanted to enable timeouts...
All requests finish ok but I want to enable timeouts as the client
seems to wait for the server before sending more requests. Example:
Test Plan (Run each Thread group separately)
Thread Group (users 100, ramp 100, count 20)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
Thread Group (users 100, ramp 100, count 30)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
Thread Group (users 100, ramp 100, count 40)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
...
...
...
Thread Group (users 100, ramp 100, count 310)
HTTP Request HTTPClient (SSL request - KeepAlive enabled)
Uniform Random Timer (Offset 100, dev 10)
Results for 10 clients (each running a JMeter instance):
Requested request rate, Average time between requests, Actual
(average) request rate
200 6.59422971 151.6477351
300 4.348678 229.9549426
400 3.276406 305.2124798
500 2.655733 376.543877
600 2.233653 447.6971132
700 1.90895 523.8481888
800 1.66188 601.7281633
900 1.465338 682.4364072
1000 1.3544235 738.3215073
1300 1.176124 850.2504838
1600 1.139619 877.4862476
1900 1.07916883 926.6390691
2200 1.008209 991.857839
2500 1.0388161 962.6342911
2800 0.97919992 1021.241914
3100 1.04185174 959.8294667
As you can see the actual request rate converges at 1000 req/s. To
check if this (100 req/s per client) is a client machine limitation I
ran the testplan against the server using only one client:
20 51.92796398 19.25744673
30 34.40246749 29.06768244
40 26.11477869 38.29249375
50 21.1030206 47.38658124
60 17.75179196 56.33234111
70 15.39391341 64.96073957
80 13.61495186 73.4486622
90 12.24736081 81.65024412
100 11.10651065 90.03727917
130 8.86183552 112.8434395
160 7.44715294 134.2795036
190 6.474603926 154.4496021
220 5.739533615 174.2301844
250 5.2158886 191.7218861
280 4.76088431 210.0450116
310 4.456917965 224.3702953
Clearly more than 100 req/s is achieved. So the client does not seem
to be the bottleneck.
So why does the client wait before sending more requests?:
Since SSL is done transparently, perhaps without knowing JMeter has to
wait for the SSL session to be established, which will take longer if
the server is busy, and so it's unknowingly 'busy' doing that instead
of making new requests..?
> > 1193316042700,32,HTTP Request HTTPClient,200,OK,Thread Group
> > 1-1,text,true,,44,7,7,https://cala01.ac.uk:8083/index.html,,32,ISO-8859-1
> >
> >
> > 1193316042484,203,HTTP Request HTTPClient,Non HTTP response code:
> > java.net.SocketTimeoutException,Non HTTP response message: Read timed
> > out,Thread Group
> > 1-4,text,false,,1815,7,7,https://cala01.ac.uk:8083/index.html,,0,ISO-8859-1
>
> This shows that the longer elapsed time is associated with the
> timeout; I assume all the longer responses are also timeouts?
Not all but the vast majority of the longer elapsed times are timeouts.
Thanks for all the help, I'm really stuck on this one
Christiaan
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Duration assertion
Posted by sebb <se...@gmail.com>.
On 26/10/2007, Christiaan Lamprecht <ch...@googlemail.com> wrote:
> > I suspect the larger size is caused by the error message when the
> > timeout happens.
> >
>
> But this shouldn't take up any bandwidth, I assume the error message
> is not from the server, the client just times out and continues. The
> test plan takes much longer when time-outs are enabled and I assumed
> it was the bandwidth due to the 1815 file size.
>
I don't understand why enabling timeouts should increase the run-time
- it might decrease, but should not increase.
If you don't use timeouts, do all the requests finish OK, or do some hang?
I'm not clear why you wanted to enable timeouts...
>
> > It would help if the success and response code fields were included in
> > the items logged.
>
> timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,grpThreads,allThreads,URL,Filename,Latency,Encoding
>
>
> 1193316042700,32,HTTP Request HTTPClient,200,OK,Thread Group
> 1-1,text,true,,44,7,7,https://cala01.ac.uk:8083/index.html,,32,ISO-8859-1
>
>
> 1193316042484,203,HTTP Request HTTPClient,Non HTTP response code:
> java.net.SocketTimeoutException,Non HTTP response message: Read timed
> out,Thread Group
> 1-4,text,false,,1815,7,7,https://cala01.ac.uk:8083/index.html,,0,ISO-8859-1
This shows that the longer elapsed time is associated with the
timeout; I assume all the longer responses are also timeouts?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Duration assertion
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
> I suspect the larger size is caused by the error message when the
> timeout happens.
>
But this shouldn't take up any bandwidth, I assume the error message
is not from the server, the client just times out and continues. The
test plan takes much longer when time-outs are enabled and I assumed
it was the bandwidth due to the 1815 file size.
> It would help if the success and response code fields were included in
> the items logged.
timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,grpThreads,allThreads,URL,Filename,Latency,Encoding
1193316042700,32,HTTP Request HTTPClient,200,OK,Thread Group
1-1,text,true,,44,7,7,https://cala01.ac.uk:8083/index.html,,32,ISO-8859-1
1193316042484,203,HTTP Request HTTPClient,Non HTTP response code:
java.net.SocketTimeoutException,Non HTTP response message: Read timed
out,Thread Group
1-4,text,false,,1815,7,7,https://cala01.ac.uk:8083/index.html,,0,ISO-8859-1
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Duration assertion
Posted by sebb <se...@gmail.com>.
On 26/10/2007, Christiaan Lamprecht <ch...@googlemail.com> wrote:
> Hi,
>
> I'm having some trouble with the Duration Assertion. I also enabled
> httpclient.timeout in the jmeter.properties file. The problem is that
> when it's enabled, the logs show that the number of bytes received per
> request is 1815 instead of 44 (44 is the size of the file requested)
> and this seems to then take up all the bandwidth. Any idea what it
> could be? Test plan and some results are below:
>
I suspect the larger size is caused by the error message when the
timeout happens.
> 10 clients, 10 JMeter instances, each running:
> Test Plan
> Thread Group (users 100, ramp 100, count 250)
> HTTP Request HTTPClient (SSL request - KeepAlive enabled)
> Duration assertion (99)
> Uniform Random Timer (Offset 100, dev 10)
>
> httpclient.timeout=99
>
>
> TimeStamp,elapsed,bytes,latency
It would help if the success and response code fields were included in
the items logged.
> ....................................
> 1193419432792,80,44,80
> 1193419432899,11,44,11
> 1193419432901,13,44,13
> 1193419432907,11,44,11
> 1193419432903,25,44,25
> 1193419432947,11,44,11
> 1193419432951,11,44,11
> 1193419433015,11,44,11
> 1193419433023,11,44,11
> 1193419433031,11,44,11
> 1193419433047,11,44,11
> 1193419433071,10,44,10
> 1193419433072,12,44,12
> 1193419433135,11,44,11
> 1193419433171,10,44,10
> 1193419433195,10,44,10
> 1193419433196,12,44,12
> 1193419433287,10,44,10
> 1193419433415,10,44,10
> 1193419433535,10,44,10
> 1193419433655,10,44,10
> 1193419433775,10,44,10
> 1193419412622,21218,1815,0
> 1193419432657,3219,1815,0
> 1193419435991,213,1815,0
> 1193419436079,217,1815,0
> 1193419433959,3209,1815,0
> 1193419434627,3217,1815,0
> 1193419437952,212,1815,0
> 1193419435075,3217,1815,0
> 1193419438404,212,1815,0
> 1193419438672,216,1815,0
> 1193419438732,212,1815,0
> 1193419439008,212,1815,0
> 1193419439060,212,1815,0
> 1193419439696,216,1815,0
> 1193419431124,9212,1815,0
> ...
> ...
> ...
>
>
> Thanks for any help in advance
> Christiaan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org