| User Manual: Simple tests |
|---|
| Web Polygraph |
The examples below are synchronized with Polygraph version 2.0.0 and should work with version 2.1.0 as well. If you find any inconsistencies, please e-mail us.
Polygraph distribution includes a client and server simulators called polyclt and polysrv. You need to run both programs to simulate the desired workload. The server(s) should be launched first. We will show the command line for polysrv (polyclt) followed by the polysrv (polyclt) output generated in our environment.
For simplicity, we will start both simulators on one machine. To run the tests below, your machine must be allowed to connect to itself via 127.0.0.1 IP address. If you want to start Polygraph on a different port or host, you must adjust configuration files accordingly.
Polygraph workloads are specified using command line options and configuration file written in Polygraph Language (PGL). PGL is documented elsewhere.
The tests and workloads described here are not meant to be used for production benchmarking! They only illustrate basic Polygraph usage.
This simple run will test basic Polygraph functionality.
Polygraph distribution already contains a simple workload specification. The specs can be found in polygraph/workloads/simple.pg. Other workload examples can be found in the polygraph/workloads/ directory as well.
Normally, the workload description includes several phases. Polygraph
stops when all phases reach their goals. For these simple tests, we will use
the default phase that does not have any goal. Hence we would have to
terminate polyclt and polysrv manually by pressing
^C or sending an interrupt signal.
Let's start the server:
sparky> ./src/polysrv --config workloads/simple.pg --verb_lvl 5 ./src/polysrv: Warning: no run phases were specified; generating and using default phase 936379568.652217| Command: ./src/polysrv --config workloads/simple.pg --verb_lvl 5 Configuration: version: 2.0.H verb_lvl: 5 prn_reqs: off prn_reps: off notify: <none> label: <none> fd_limit: 11906 config: workloads/simple.pg cfg_dirs: console: - log: <none> log_size: 65536 file_scan: select fake_hosts: idle_tout: <none> rng_seed: 1 936379568.652217| FDs: 12288 out of 12288 FDs can be used; safeguard limit: 11906 936379568.652217| run-id: 24033890.193807607:2 pid: 17655 936379568.652217| waiting for traffic 936379568.917841| agent `S101' starting on 127.0.0.1:8080 936379573.921299| i-dflt 0 0.00 -1 -1.00 0 1 936379578.671395| i-dflt 0 0.00 -1 -1.00 0 1 936379583.671515| i-dflt 0 0.00 -1 -1.00 0 1
As you can see, the server started on localhost (127.0.0.1), port 8080. Polysrv complained about no phases found in workloads/simple.pg and generated a ``default'' infinite phase. Since there is no client running yet, the run-time statistics are all zeros. For details about console output format look elsewhere.
Polysrv will continue to do nothing until we start the client:
sparky> ./src/polyclt --config workloads/simple.pg --verb_lvl 5 ./src/polyclt: Warning: no run phases were specified; generating and using default phase 936379587.403493| Command: ./src/polyclt --config workloads/simple.pg --verb_lvl 5 Configuration: version: 2.0.H verb_lvl: 5 prn_reqs: off prn_reps: off notify: <none> label: <none> fd_limit: 11906 config: workloads/simple.pg cfg_dirs: console: - log: <none> log_size: 65536 file_scan: select fake_hosts: idle_tout: <none> rng_seed: 1 proxy: <none> ports: <none> ign_false_hits: on prn_false_misses: off world_type: Polygraph world_id: 24033909.1562264827:2 world_urls: <none> unique_urls: -1 recur: -1.00 pop_model: zipf() tmp_loc: <none> tmp_loc_delta: 1 tmp_loc_depth: 500000 prefilled_cnt: -1 936379587.403493| FDs: 12288 out of 12288 FDs can be used; safeguard limit: 11906 936379587.403493| run-id: 24033909.1562264827:4 pid: 17659 936379587.403493| waiting for traffic 936379587.666856| agent `R101' starting on 127.0.0.1 936379592.403624| i-dflt 4126 825.18 1 0.00 0 1 936379597.404028| i-dflt 8432 861.13 1 0.00 0 1 936379602.403750| i-dflt 12721 857.85 1 0.00 0 1 936379607.403969| i-dflt 17015 858.76 1 0.00 0 1 936379612.403611| i-dflt 21271 851.26 1 0.00 0 1 936379617.403821| i-dflt 25566 858.96 0 0.00 0 1 936379622.403504| i-dflt 29854 855.65 1 0.00 0 1 936379627.404284| i-dflt 34177 864.47 0 0.00 0 1 936379632.403672| i-dflt 38445 853.70 1 0.00 0 1 936379637.403588| i-dflt 42736 858.21 1 0.00 0 1 936379642.404141| i-dflt 47021 856.91 0 0.00 0 1 936379647.403631| i-dflt 51301 856.09 0 0.00 0 1
Now we can see some traffic on both client (above) and server (below) sides. The console output tells us that Polygraph is doing around 855 req/sec with response times around 1 msec, and that there are no hits or errors. Note that we are running a very simple back-to-back workload. Your numbers will differ depending how powerful your OS and hardware are.
We will kill the experiment now by pressing Control-C in client and server windows. Here is the rest of the server output:
936379583.671515| i-dflt 0 0.00 -1 -1.00 0 1 936379588.652365| i-dflt 885 177.68 0 0.00 0 2 936379593.652279| i-dflt 5198 862.61 0 0.00 0 2 936379598.652431| i-dflt 9501 860.57 0 0.00 0 2 936379603.652708| i-dflt 13804 860.55 0 0.00 0 1 936379608.652268| i-dflt 18065 852.28 0 0.00 0 1 936379613.652678| i-dflt 22341 855.13 0 0.00 0 2 936379618.652818| i-dflt 26641 859.98 0 0.00 0 1 936379623.652745| i-dflt 30916 855.01 0 0.00 0 1 936379628.652259| i-dflt 35223 861.48 0 0.00 0 1 936379633.652519| i-dflt 39527 860.76 0 0.00 0 1 936379638.652419| i-dflt 43809 856.42 0 0.00 0 1 936379643.652452| i-dflt 48073 852.79 0 0.00 0 1 936379653.003042| i-dflt 51791 397.62 0 0.00 0 1 936379653.663042| i-dflt 51791 0.00 -1 -1.00 0 1 ^Cgot shutdown signal (2) 936379653.820356| noticed shutdown signal (2) 936379653.820356| server 127.0.0.1:8080 is closing listen socket 3 936379653.820547| got 51791 xactions and 0 errors 936379653.820547| shutdown reason: got shutdown signal
And the rest of the client output:
936379647.403631| i-dflt 51301 856.09 0 0.00 0 1 ^Cgot shutdown signal (2) 936379647.972153| noticed shutdown signal (2) 936379647.972269| got 51790 xactions and 0 errors 936379647.972269| shutdown reason: got shutdown signal sparky>
Now it is a good time for you to look through workloads/simple.pg and PGL documentation to see what kind of workload we were using during this simple test.
In the previous test, polyclt was talking directly to polysrv running on port 8080. Now we want to introduce a proxy into the setup.
If your proxy runs in a transparent mode, you will probably need to run polyclt and polysrv on different hosts and move polysrv to port 80 so that Polygraph traffic will get automagically redirected to the proxy. We will not demonstrate transparent setup here.
Our proxy is running on host 10.0.1.204 and listening for HTTP queries on port 8080. We need to tell polyclt process which proxy to connect to using the --proxy option.
Another complication is that we can no longer use loopback interface and have to move our server to an address that a proxy can connect to. Server IP address is specified in the workloads/simple.pg configuration file. Here are the relevant lines:
addr[] srv_ips = ['127.0.0.1:8080' ]; // localhost addr[] rbt_ips = ['127.0.0.1' ]; // localhost
You will need to edit those lines to change 127.0.0.1 IP to the IP of your machine (e.g., our machine is 10.0.1.4). We recommend that you do not edit workloads/simple.pg but create and edit its copy. Let's call that modified file workloads/my-simple.pg.
Finally, we want to add some detailed logging to this experiment using the --log option.
A sample from the server output is below:
sparky> ./src/polysrv --config workloads/my-simple.pg --log /tmp/ts.log --verb_lvl 5 ... 936385645.998796| waiting for traffic 936385646.264569| agent `S101' starting on 10.0.1.4:8080 ... 936385671.015987| i-dflt 0 0.00 -1 -1.00 0 1 936385675.999056| i-dflt 108 21.67 0 0.00 0 2 936385681.001725| i-dflt 1039 186.10 0 0.00 0 2 936385685.999915| i-dflt 1970 186.27 0 0.00 0 2 936385691.003609| i-dflt 2890 183.86 0 0.00 0 2 936385695.999295| i-dflt 3797 181.56 1 0.00 0 2 936385700.999228| i-dflt 4589 158.40 1 0.00 0 2 936385706.000524| i-dflt 5312 144.56 0 0.00 0 2 936385711.001286| i-dflt 5957 128.98 1 0.00 0 2 936385716.001420| i-dflt 6604 129.40 0 0.00 0 2 936385721.000350| i-dflt 7181 115.42 0 0.00 0 2 936385726.001608| i-dflt 7858 135.37 0 0.00 0 2 936385731.037662| i-dflt 8410 109.61 0 0.00 0 2 936385736.039301| i-dflt 8934 104.77 0 0.00 0 2 ... ^Cgot shutdown signal (2) 936385797.876034| i-dflt 15033 43.92 0 0.00 0 1 936385797.876034| noticed shutdown signal (2) 936385797.876034| server 10.0.1.4:8080 is closing listen socket 3 936385797.876450| got 15033 xactions and 0 errors 936385797.876450| shutdown reason: got shutdown signal
And here is the client output. If you are running Polygraph 2.0.0, you need to use --recur option to offer 55% URL ``revisit'' ratio (hit ratio is recurrence ratio adjusted for object cachability). Later versions of Polygraph have recurrence ratio specified in the workload configuration file.
sparky> ./src/polyclt --config workloads/my-simple.pg --proxy 10.0.1.204:8080 \ --recur 55p --log /tmp/tc.log --verb_lvl 5 ... 936385675.465891| agent `R101' starting on 10.0.1.4 936385680.202501| i-dflt 1808 361.79 2 50.39 1 1 936385685.202393| i-dflt 3604 359.21 2 48.27 0 1 936385690.202625| i-dflt 5402 359.58 2 48.11 0 1 936385695.202701| i-dflt 7188 357.19 2 49.72 0 1 936385700.202419| i-dflt 8738 310.02 3 48.06 0 1 936385705.208645| i-dflt 10148 281.65 3 46.95 0 1 936385710.211261| i-dflt 11382 246.67 4 47.57 0 1 936385715.205513| i-dflt 12593 242.48 4 46.90 0 1 936385720.205920| i-dflt 13727 226.78 4 47.27 0 1 936385725.202504| i-dflt 14897 234.16 4 44.19 0 1 936385730.202990| i-dflt 15986 217.78 4 48.30 0 1 936385735.202422| i-dflt 16989 200.62 4 47.16 0 1 936385740.203324| i-dflt 18051 212.36 4 51.13 0 1 936385745.202814| i-dflt 19051 200.02 5 44.40 0 1 936385750.202450| i-dflt 20066 203.01 4 47.59 0 1 936385755.202505| i-dflt 21141 215.00 4 49.58 0 1 936385760.231017| i-dflt 22124 195.49 5 46.49 0 1 936385765.204151| i-dflt 23139 204.10 4 45.12 0 1 936385770.209517| i-dflt 24107 193.39 5 47.62 0 1 936385775.202392| i-dflt 25065 191.87 5 48.64 0 1 936385780.203502| i-dflt 26072 201.36 4 44.49 0 1 936385785.205360| i-dflt 27034 192.33 5 48.34 0 1 936385790.207532| i-dflt 28000 193.12 5 46.79 0 1 ^Cgot shutdown signal (2) 936385793.966356| noticed shutdown signal (2) 936385793.966462| got 28765 xactions and 0 errors 936385793.966462| shutdown reason: got shutdown signal
Note that request rate has dropped to about 200 req/sec due to various extra overheads not present in our first back-to-back setup. Also, polyclt is now getting some hits (~48%).
If you are not getting any hits from a proxy while everything else works as expected, it is possible that the proxy under test is picky about object expiration time and other freshness info. Some proxies would not cache an object without certain HTTP header fields. The simple workload we are using here does not have Object Life Cycle model configured, and servers generate no freshness headers. To get hits, you can either use a more advanced workload (e.g., workloads/polymix-1.pg) or modify your workload specs to include Object Life Cycle model.
The binary logs created during the last test can be analyzed with the lr (``Log Reader'') and lx (``Log Extractor'') tools included in the Polygraph distribution. For example, to get response time histogram on the client side (after the experiment is over), one might type:
sparky> src/lx --objects rptm_hist /tmp/tc.log
rptm_hist:
# bin min max count % acc%
1 0 1 4884 36.35 36.35
3 2 2 4203 31.28 67.63
4 3 3 1442 10.73 78.36
5 4 4 1223 9.10 87.46
6 5 5 558 4.15 91.61
7 6 6 326 2.43 94.04
8 7 7 196 1.46 95.50
9 8 8 119 0.89 96.38
10 9 10 105 0.78 97.16
12 11 14 128 0.95 98.12
16 15 20 129 0.96 99.08
22 21 87 124 0.92 100.00
You can get most of the aggregate stats collected during the experiment by running
./src/lx /tmp/tc.log | less