Here are a few examples of very simple Polygraph executions.

Hello, World!

Your machine must be allowed to connect to itself (via 127.0.0.1 IP address) to run this test.

Let's try to simulate 10 clients talking to a single server listening on port 8080 of the localhost:

pail> ./polygraph 10 8080
Polygraph. Version 0.0. Date: 1998/09/21 21:43:07  (c) 1998
usage: ./polygraph [option ...] <clients> [listen_port# ...]
clients:
  <num>x<count>         'stream' workload:  num clients, count requests each
                          requests are submitted as replies are received
  <num>x<count>r<rate>  'poisson' workload: cumulative req rate
                          rate is an average submission rate in req/sec
  <0>                   no clients (server-only mode)
options:
  --host <name>         origin server host (affects URL generation)
  --proxy <IP:port#>    proxy address (affects connect(2) requests)
  --world <id:count>    numerical world id and #objects in the world
                          use 'max' for maximum #objects
  --seq <seed>          sequential object ids; ids start with seed
  --rnd <seed>          random object ids; r.n.g seeded with seed
                          ids are distributed as zipf(1)
  --unique <seed>       append unique ids to urls; ids start with seed
  --obj_size <kbytes>   mean object size
URL format (abridged):
  http://host_name/obj_id/world_id
 or
  http://host_name/obj_id/world_id/unique_id
pail>

Apparently it did not work. By looking at the usage summary, you can see that I have omitted the number of requests per client. Let's try again:

pail> ./polygraph 10x10 8080
Command: ./polygraph 10x10 8080
configuration:
        OriginAddr:      localhost:8080
        ProxyAddr:       127.0.0.1:8080
        WorldId:         1
        WorldCapacity:   1073741824 objects
        SeqStart:        -1
        RndSeed:         1
        UniqStart:       -1
        ObjSizeMean:     13312 bytes
        ClientCount:     10
        ReqPerClient:    10
        ClntThinkTime:   -1.00 seconds
        ServerCount:     1
        ServerPorts:     8080
workload:   stream
obj_id_gen: random
unique_url_gen: disabled
Max_FD: 1024
# warm-up phase completed in 39 msec after 20 submission
# warm-up: subm:         20 960.29       compl:  0 -1.00         err:    0      left:    20
# measurement phase completed in 323 msec after 88 submissions
# measurement: subm:     88 308.56       compl:  89 300.55       err:    0      left:    -1
^C
execution time: 6.728 sec

... snip ...

server   subm    s/sec   compl   c/sec   errs    left
     0   100     146.38  100     149.93  0       0
sum      100     146.38  100     149.93  0       0

client   subm    s/sec   compl   c/sec   errs    left
     0   10      17.35   10      16.33   0       0
     1   10      15.80   10      16.23   0       0
     2   10      16.09   10      17.06   0       0
     3   10      20.44   10      19.58   0       0
     4   10      15.04   10      16.71   0       0
     5   10      14.25   10      16.26   0       0
     6   10      15.21   10      16.96   0       0
     7   10      18.99   10      18.25   0       0
     8   10      15.80   10      16.80   0       0
     9   10      16.09   10      19.08   0       0
sum      100     142.50  100     154.25  0       0
middle   88      308.56  89      300.55  0       -1
906442609.261806! server 00:10 closed listen socket 3
pail>

It worked! Except I had to send an INTR signal (pressed ^C) to stop the process. You see, we are simulating both clients and servers in one process. This is an unusual mode. The server has a long idle timeout period so I decided to stop it before it expires. You will appreciate long server timeouts when simulating a server using a separate process (no need to restart it all the time).

For various reasons, you should not use the same process for simulating servers and clients in real tests.

The line at the bottom that starts with "middle" contains aggregate statistics for the experiment. It says that during the measurement phase, 88 requests were sent at the rate of 308.56 requests per second. Also, 89 responses were received at the rate of 300.55. There were 0 errors and -1 request was still pending when the measurement phase completed.

The -1 pending request count may look like a bug, but it is not. Since the duration of the measurement phase is determined semi-concurrently with actual submissions of the requests, some discrepancy is OK. The totals ("sum" line) do not have this problem.

To avoid warm-up and cool-off side effects you should use "middle" line rather than "sum".

Finally, you can get similar results by running two concurrent programs, one as a client and one as a server:

pail> ./polygraph 0 8080 > /tmp/s & # server (no clients)
[1] 19905
pail> ./polygraph 10x10 > /tmp/c &  # client (no listen ports)
[2] 19907
pail>
[2]+  Done                    ./polygraph 10x10 >/tmp/cl
pail> tail /tmp/cl
     2   10      18.95   10      21.14   0       0
     3   10      17.07   10      17.68   0       0
     4   10      16.20   10      17.94   0       0
     5   10      13.78   10      15.40   0       0
     6   10      14.91   10      16.81   0       0
     7   10      13.52   10      15.06   0       0
     8   10      13.78   10      15.36   0       0
     9   10      13.24   10      16.41   0       0
sum      100     132.44  100     146.00  0       0
middle   81      139.73  85      146.63  0       -4
pail> 

The results are quite different! This is one of the reasons why you should not run client and server as one process. That mode is useful for debugging purposes only.

Note that I did not have to stop my client process this time, and my server is still running.