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.

  

--
Patrick O'Leary


You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles.
 Do you understand this? 
And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat.
  - Albert Einstein
View Patrick O Leary's LinkedIn profileView Patrick O Leary's profile

-- 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.

Reply via email to