|
Home > Archive > AOL Webserver > October 2007 > Problem with Apache Bench: 2c-1 requests
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Problem with Apache Bench: 2c-1 requests
|
|
| Tom Jackson 2007-10-20, 1:11 am |
| 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
| |
| patrick o'leary 2007-10-20, 1:11 am |
| 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 <listserv@listserv.aol.com> 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
<http://www.linkedin.com/in/pjaol>
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <listserv@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
| |
| Tom Jackson 2007-10-20, 7:11 am |
| 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:[vbcol=seagreen]
> 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:
|
|
|
|
|