[httperf] A strange output

Arlitt, Martin martin.arlitt at hp.com
Fri Mar 30 06:13:07 PST 2007

Hi John


I believe httperf is functioning in an expected manner.  In the original
example you sent, take a look at the session histogram; it shows 42
sessions had 20 requests/replies, and 78 that had 1 request/reply.
42+78=120, which means httperf did generate 120 sessions as requested,
but 78 of them were failed sessions.  If you have logs enabled on your
server you could check if they contain any information about potential
errors on the server that would have caused this.  Since there were 226
connections reset by the server, this indicates that even if the 78
failed sessions were due to the server resetting the connections, there
were a lot of other connections that were reset before httperf issued a
request.  Thus, httperf did retry the sessions for which the connection
was reset before sending a request, but it does not retry sessions that
failed after a request was sent and a reply received.  Based on the man
page, this is what I expect should happen.


I still do not understand why you expect the server to reset a
connection after every 2 successful requests.   It would be helpful to
know why this is happening.


The difference between the original test you sent and the other tests
you described is some of the sessions failed in the original test, and
httperf does not retry a failed session.  In the other tests you
described, none of the sessions have failed sessions, even if there are
reset connections.





From: John Talbot [mailto:jtalbot at proionta.gr] 
Sent: Friday, March 30, 2007 6:52 AM
To: Arlitt, Martin; httperf at napali.hpl.hp.com
Subject: Re: [httperf] A strange output


Indeed. The session file is a single small-ish file repeated 20 times.

I did some more test immediately after this output, and found that the
server resets the connection after every 2 successful requests (given
that all these requests are asking for the same file/URL).
Furthermore the output I pasted was not reproducible. All subsequent
tests produced exactly 9 connresets for every session, as expected, and
all sessions were successful in the histogram.

But the question is this: why didn't httperf, in this particular httperf
run that I pasted, retry sessions that had connresets until it either
got a different error (like client-timo) or a successful session? What
could be the reasons that caused that? Wouldn't that be httperf's
expected behaviour? [Or does, for example, httperf quit a session when a
connreset occurs before the first request in a session?]

- John

Arlitt, Martin wrote: 

Hi John


Without more details of your test session and your test environment it
is difficult to know exactly what the cause of the problem is.  However,
it appears that for some subset of requests, the server is resetting the
connections.  In some cases this happens before httperf has sent a
request on the connection, and in some cases afterwards.  I suggest
spending some time to determine why the server is resetting these
connections; given the small number of concurrent connections you are
using, I find this behavior a bit surprising.





From: httperf-bounces at napali.hpl.hp.com
[mailto:httperf-bounces at napali.hpl.hp.com] On Behalf Of John Talbot
Sent: Thursday, March 29, 2007 6:41 PM
To: httperf at napali.hpl.hp.com
Subject: [httperf] A strange output


I got the following weird output on an httperf run I did:

It's completely mystifying what might have produced this output - is it
a problem on the target server, a problem on the host running httperf,
or both?

What seems strange to me about it is that it appears that httperf
doesn't retry the connections which were "connreset" here (my until now
experience with httperf has been that reset connections were retried and
resulted in either a successful sessions or in some other type of

But here all the errors are connreset - could someone please enlighten
me as to what might be going on?

Thanks in advance,
- John


httperf --timeout=5 --client=0/1 --server=myserver --port=80 --uri=/
--max-connections=2 --max-piped-calls=25 --rate=1 --send-buffer=4096
--recv-buffer=16384 --wsesslog=120,0.000,/urls-list 
Maximum connect burst length: 1 

Total: connections 268 requests 1066 replies 840 test-duration 119.116 s

Connection rate: 2.2 conn/s (444.5 ms/conn, <=2 concurrent connections) 
Connection time [ms]: min 5.3 avg 25.3 max 91.9 median 16.5 stddev 17.9 
Connection time [ms]: connect 2.3 
Connection length [replies/conn]: 4.421 

Request rate: 8.9 req/s (111.7 ms/req) 
Request size [B]: 105.0 

Reply rate [replies/s]: min 0.0 avg 6.4 max 20.0 stddev 9.3 (23 samples)

Reply time [ms]: response 3.3 transfer 0.0 
Reply size [B]: header 387.0 content 54.0 footer 0.0 (total 441.0) 
Reply status: 1xx=0 2xx=840 3xx=0 4xx=0 5xx=0 

CPU time [s]: user 88.62 system 29.72 (user 74.4% system 25.0% total
Net I/O: 4.0 KB/s (0.0*106 bps) 

Errors: total 226 client-timo 0 socket-timo 0 connrefused 0 connreset
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0 

Session rate [sess/s]: min 0.00 avg 0.35 max 1.00 stddev 0.47 (42/120) 
Session: avg 4.52 connections/session 
Session lifetime [s]: 0.1 
Session failtime [s]: 0.0 
Session length histogram: 78 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 42 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/httperf/attachments/20070330/f406a8ad/attachment.htm

More information about the httperf mailing list