[httperf] Httperf concurrent/rate implementation.

Martin Arlitt arlitt at granite.hpl.hp.com
Tue Mar 9 07:28:47 PST 2004


my understanding is that you were trying to support 200 concurrent
persistent connections while maintaining a request rate of 50 requests per
second.  here is how I would do that.

by default httperf will use a separate persistent connection for each
session.  thus to have 200 concurrent persistent connections, we could
use 200 concurrent sessions.  While one could simply define 200 very long
sessions (e.g., thousands of requests per session), I'd recommend doing
something more realistic, like having old sessions finish, and new
sessions start, while maintaining (on average) a desired number of
concurrent sessions.

First you will need to define the characteristics of a session.  please
realize that there are many ways to do this, but I will show only one of
them.  to keep the example as simple as possible, I am going to assume
that all sessions are identical (i.e., I will only define one session).
The first thing to do is to decide on the number of requests per session.
For this example I will use 11 requests per session.

Next, we need to determine the inter-request times.  For this simple
example I am assuming that each request transfers an entire document
(i.e., there are no embedded requests in this example, which would not
have user think times between them).  To achieve the desired request rate
we calculate the following:

50 reqs/sec = (200 concurrent sessions * 11 reqs/session)/X secs/session

X = 2200/50 = 44 seconds

Thus the (average) duration of a session should be 44 seconds in order to
achieve the desired request rate, given the desired number of concurrent
sessions and the number of requests per session.

The (average) user think time is:

session duration.(number of requests per session - 1) = 44/10 = 4.4 seconds

we can now define an input file to be used with --wsesslog:

/1.html think=4.4
/2.html think=4.4
/3.html think=4.4
/4.html think=4.4
/5.html think=4.4
/6.html think=4.4
/7.html think=4.4
/8.html think=4.4
/9.html think=4.4
/10.html think=4.4
/11.html think=4.4

please note that this is a very simple example, once you understand the
basic ideas you can start creating more realistic sessions.

The next thing to do is to determine how long to run the experiment.
please be aware that initially there will be fewer than 200 concurrent
sessions (the ramp up period).  At the end of the experiment there will
also be fewer than 200 concurrent sessions (the ramp down period).  These
each last about 1 session duration.  You then need to choose a length L
for the stable period such that you have sufficient time to observe the
server behavior during the stable period, and are not observing transient
behavior during the ramp up or ramp down periods.

in case that is not clear, you may want to graph the number of concurrent
sessions (which should be the number of concurrent TCP connections if you
use a persistent connection for each session).  the graph should look
something like:
/        \

where '/' is the ramp up period and '\' is the ramp down period.

We also need to calculate the session arrival rate:

rate = (number of concurrent users)/(session duration) = 200/44 = 4.5454

the period is 1/rate or 0.22.

to keep the example simple, I chose to generate 200,000 sessions.  knowing
that the session arrival rate is 4.5454 per second, we can calculate the
duration of the experiment:  200,000/4.5454 = 44000.528 seconds

L in this case is about 43912 seconds, which is just over 12 hours.  you
probably do not want to start out with such a large value until you are
confident that every thing is configured as you want it.  I chose this
value simply as an example.

that should be all of the calculations you need to start with.  once you
have played with that example for a while, you can work on improving the
realism, by defining additional sessions, with different requests,
embedded requests, session lengths, think time distributions, etc.

below is the httperf output from an experiment that used the information
we derived in the above example:

$ ./httperf --server= --period=0.22 --wsesslog=200000,0,session.txt
httperf --client=0/1 --server= --port=80 --uri=/ --rate=4.54545 --s\
end-buffer=4096 --recv-buffer=16384 --wsesslog=200000,0.000,session.txt
Maximum connect burst length: 1

Total: connections 200000 requests 2200000 replies 2200000 test-duration
44050.825 s

Connection rate: 4.5 conn/s (220.3 ms/conn, <=238 concurrent connections)
Connection time [ms]: min 44007.1 avg 47705.0 max 52338.7 median 47707.5 stddev 2053.9
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 11.000

Request rate: 49.9 req/s (20.0 ms/req)
Request size [B]: 69.0

Reply rate [replies/s]: min 2.0 avg 49.9 max 65.0 stddev 5.5 (44054 samples)
Reply time [ms]: response 336.6 transfer 0.0
Reply size [B]: header 284.0 content 1024.0 footer 0.0 (total 1308.0)
Reply status: 1xx=0 2xx=2200000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 11832.55 system 32218.43 (user 26.9% system 73.1% total 100.0%)
Net I/O: 67.2 KB/s (0.6*10^6 bps)

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

Session rate [sess/s]: min 0.00 avg 4.54 max 10.00 stddev 1.48 (200000/200000)
Session: avg 1.00 connections/session
Session lifetime [s]: 47.7
Session failtime [s]: 0.0
Session length histogram: 0 0 0 0 0 0 0 0 0 0 0 200000

as I stated in a previous message, you will need other sources of
information for examining the behavior of the server during the stable
period.  the httperf output does provide some information that indicates
the experiment worked as we wanted (e.g., the request and reply rates are
49.9/second, very close to the desired 50/second), but other pieces of
data are less informative (e.g., why is the average session lifetime 47.7
seconds?).  you'll need to use other tools to better understand the system


On Mon, 23 Feb 2004, Rivalino Matias Jr. wrote:

> Hi Martin,
> Thank you for the explanations. I'm going to use the session like you  said.
> I´m trying to use the --wsesslog in order to model my workload.  I got an
> error msg when using --period and --rate parameters inside of session file.
> My files are:
> MysampleFile-01:
> #----
> /foo1.html rate=10
> /foo2.html rate=20
> #-----
> or
> MysampleFile-02:
> #----
> /foo1.html period=e0.5
> /foo2.html period=e0.02
> #----
> Trying to use these files, I did:
> % httperf --wsesslog=10,0,MysampleFile-0x  --server= .....
> The result was the follow msg:
> httperf: did not recognize arg 'period=e0.5' in MysampleFile-02.
> What is my mistake ?
> Is it possible to define a --period or --rate for each session inside the
> file ?
> Thank you very much ! Your support is being valuable.
> Rivalino.
> From: "Martin Arlitt" <arlitt at granite.hpl.hp.com>
> To: "Rivalino Matias Jr." <rivalino at eps.ufsc.br>
> Cc: <httperf at napali.hpl.hp.com>
> Sent: Monday, February 23, 2004 12:00 PM
> Subject: Re: [httperf] Httperf concurrent/rate implementation.

More information about the httperf mailing list