Thanks, I believe that explains the results perfectly. I guess -n should stand for the number of results, not the number of requests.
I'll look into JMeter. tom jackson On Friday 19 October 2007 22:08, patrick o'leary wrote: > apache bench mark will dispatch requests up until it's received -n > number of responses. > e.g. > with concurrency of 3 (c1, c2, c3), and -n 3 requests > > c1 -> send request 1 > c2 -> send request 2 > c3 -> send request 3 > > c1 <- response 1 > # of responses < 3 > c1 -> send request 4 > > c2 <- response 2 > # of responses < 3 > c2 -> send request 5 > > c3 <- response 3 > # of responses > 3 > wait for clients to end and report > > Hopefully if the above makes sense, you should see that ab will continue > to dispatch requests until it gets > all the necessary responses back. > > Since ab 1.3 it's acted like this, same sort of thing with microsoft > stress tool, JMeter is probably the only thing > I've found accurate enough for precision testing rather than capacity > testing. > > HTH > P > > Tom Jackson wrote: > > When I run apache bench like this: > > > > $ ab -n 3 -c 3 http://192.168.1.102:8000/bgwrite/sns-thumb.jpg > > > > I expect that it will send exactly three requests using three different > > connections. > > > > In fact, the summary tells me exactly that: > > > > -------------- > > Server Software: AOLserver/4.5.0 > > Server Hostname: 192.168.1.102 > > Server Port: 8000 > > > > Document Path: /bgwrite/sns-thumb.jpg > > Document Length: 28672 bytes > > > > Concurrency Level: 3 > > Time taken for tests: 6.21440 seconds > > Complete requests: 3 > > Failed requests: 0 > > Write errors: 0 > > Total transferred: 86658 bytes > > HTML transferred: 86016 bytes > > Requests per second: 0.50 [#/sec] (mean) > > Time per request: 6021.440 [ms] (mean) > > Time per request: 2007.147 [ms] (mean, across all concurrent > > requests) Transfer rate: 13.95 [Kbytes/sec] received > > --------------------- > > > > But last week I noticed something weird, then forgot about it. If the > > concurrency was 'c', I would get 'c-1' extra requests. These were logged > > in the defective prequeue filter in the driver thread before being > > queued. The access log also recorded extra hits. For instance, the above > > command to ab will produce exactly 5 access.log entries. > > > > I noticed this again today when I did 50 requests with concurrency=50. I > > got 99 requests logged, but apache bench checked out early and did the > > report after 50. I only noticed this because I had only one thread > > configured and there was a 0-5 second delay for each request. Long after > > the report showed up, AOLserver was chugging away logging what it was > > doing, and the access log did the same. > > > > So I thought either AOLserver is duplicating this stuff or Apache Bench > > is doing it. I guess if I had considered the fact that AOLserver has no > > idea what the concurrency is, it would have been obvious. > > > > I then used netstat to show if there were actually 5 connections or just > > three: > > > > Prior to running ab: > > Active Internet connections (w/o servers) > > Proto Recv-Q Send-Q Local Address Foreign Address State > > tcp 1 0 192.168.1.101:33180 207.228.252.10:80 > > CLOSE_WAIT tcp 0 0 127.0.0.1:9997 127.0.0.1:56705 > > ESTABLISHED tcp 0 0 127.0.0.1:56705 127.0.0.1:9997 > > ESTABLISHED tcp 0 0 192.168.1.101:45825 > > 216.211.130.179:110 TIME_WAIT > > > > > > Just after running ab: > > Active Internet connections (w/o servers) > > Proto Recv-Q Send-Q Local Address Foreign Address State > > tcp 1 0 192.168.1.101:33180 207.228.252.10:80 > > CLOSE_WAIT tcp 1 0 192.168.1.102:8000 > > 192.168.1.102:49737 CLOSE_WAIT tcp 1 0 192.168.1.102:8000 > > 192.168.1.102:49736 CLOSE_WAIT tcp 0 0 > > 192.168.1.102:8000 192.168.1.102:49735 TIME_WAIT tcp 0 > > 0 192.168.1.102:8000 192.168.1.102:49734 TIME_WAIT tcp > > 0 0 192.168.1.102:8000 192.168.1.102:49733 TIME_WAIT tcp > > 0 0 192.168.1.102:49737 192.168.1.102:8000 FIN_WAIT2 > > tcp 0 0 192.168.1.102:49736 192.168.1.102:8000 > > FIN_WAIT2 tcp 0 0 192.168.1.102:49738 192.168.1.102:8000 > > TIME_WAIT ... > > > > The extra two are in CLOSE_WAIT, from ports 49736-7 > > > > I'm not sure what the exact significance of this is, but we are > > benchmarking stuff which we are not sure is working. It appears that the > > tool I am using is somewhat broken itself. > > > > I wonder if this analysis is correct, and if so, are there other > > benchmarking tools we could use? > > > > tom jackson > > > > > > -- > > AOLserver - http://www.aolserver.com/ > > > > To Remove yourself from this list, simply send an email to > > <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the > > email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
