On 27/10/2007, Christiaan Lamprecht <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
