From 20f712c14ae9bf73e2314a1641760aeccfcc1c7e Mon Sep 17 00:00:00 2001 From: RiyaTyagi <31857310+RiyaTyagi@users.noreply.github.com> Date: Tue, 5 May 2020 04:13:56 +0530 Subject: [PATCH] benckmarks: integrated the two README.md The readme file present at "benchmarks/src/jmh/java/io/grpc/benchmarks/netty/README.md" is integrated with readme at "benchmarks/README.md". --- benchmarks/README.md | 40 +++++++++++++++++ .../java/io/grpc/benchmarks/netty/README.md | 45 ------------------- 2 files changed, 40 insertions(+), 45 deletions(-) delete mode 100644 benchmarks/src/jmh/java/io/grpc/benchmarks/netty/README.md diff --git a/benchmarks/README.md b/benchmarks/README.md index 29c107d728..48933fff88 100644 --- a/benchmarks/README.md +++ b/benchmarks/README.md @@ -17,6 +17,46 @@ You can now find the client and the server executables in `benchmarks/build/inst The `C++` counterpart can be found at https://github.com/grpc/grpc/tree/master/test/cpp/qps +The [netty benchmark](src/jmh/java/io/grpc/benchmarks/netty) directory contains +the standard benchmarks used to assess the performance of GRPC. Since these +benchmarks run on localhost over loopback the performance of the underlying network is considerably +different to real networks and their behavior. To address this issue we recommend the use of +a network emulator to make loopback behave more like a real network. To this end the benchmark +code looks for a loopback interface with 'benchmark' in its name and attempts to use the address +bound to that interface when creating the client and server. If it cannot find such an interface it +will print a warning and continue with the default localhost address. + +To attempt to standardize benchmark behavior across machines we attempt to emulate a 10gbit +ethernet interface with a packet delay of 0.1ms. + +### Linux + +On Linux we can use [netem](https://www.linuxfoundation.org/collaborate/workgroups/networking/netem) to shape the traffic appropriately. + +```sh +# Remove all traffic shaping from loopback +sudo tc qdisc del dev lo root +# Add a priority traffic class to the root of loopback +sudo tc qdisc add dev lo root handle 1: prio +# Add a qdisc under the new class with the appropriate shaping +sudo tc qdisc add dev lo parent 1:1 handle 2: netem delay 0.1ms rate 10gbit +# Add a filter which selects the new qdisc class for traffic to 127.127.127.127 +sudo tc filter add dev lo parent 1:0 protocol ip prio 1 u32 match ip dst 127.127.127.127 flowid 2:1 +# Create an interface alias call 'lo:benchmark' that maps 127.127.127.127 to loopback +sudo ip addr add dev lo 127.127.127.127/32 label lo:benchmark +``` + +to remove this configuration + +```sh +sudo tc qdisc del dev lo root +sudo ip addr del dev lo 127.127.127.127/32 label lo:benchmark +``` + +### Other Platforms + +Contributions are welcome! + ## Visualizing the Latency Distribution The QPS client comes with the option `--save_histogram=FILE`, if set it serializes the histogram to `FILE` which can then be used with a plotter to visualize the latency distribution. The histogram is stored in the file format of [HdrHistogram](https://hdrhistogram.org/). That way it can be plotted very easily using a browser based tool like https://hdrhistogram.github.io/HdrHistogram/plotFiles.html. Simply upload the generated file and it will generate a beautiful graph for you. It also allows you to plot two or more histograms on the same surface in order two easily compare latency distributions. diff --git a/benchmarks/src/jmh/java/io/grpc/benchmarks/netty/README.md b/benchmarks/src/jmh/java/io/grpc/benchmarks/netty/README.md deleted file mode 100644 index 64943e0540..0000000000 --- a/benchmarks/src/jmh/java/io/grpc/benchmarks/netty/README.md +++ /dev/null @@ -1,45 +0,0 @@ -Benchmarks -========== - -This directory contains the standard benchmarks used to assess the performance of GRPC. Since these -benchmarks run on localhost over loopback the performance of the underlying network is considerably -different to real networks and their behavior. To address this issue we recommend the use of -a network emulator to make loopback behave more like a real network. To this end the benchmark -code looks for a loopback interface with 'benchmark' in its name and attempts to use the address -bound to that interface when creating the client and server. If it cannot find such an interface it -will print a warning and continue with the default localhost address. - -To attempt to standardize benchmark behavior across machines we attempt to emulate a 10gbit -ethernet interface with a packet delay of 0.1ms. - - -Linux -===== - -On Linux we can use [netem](https://www.linuxfoundation.org/collaborate/workgroups/networking/netem) to shape the traffic appropriately. - -```sh -# Remove all traffic shaping from loopback -sudo tc qdisc del dev lo root -# Add a priority traffic class to the root of loopback -sudo tc qdisc add dev lo root handle 1: prio -# Add a qdisc under the new class with the appropriate shaping -sudo tc qdisc add dev lo parent 1:1 handle 2: netem delay 0.1ms rate 10gbit -# Add a filter which selects the new qdisc class for traffic to 127.127.127.127 -sudo tc filter add dev lo parent 1:0 protocol ip prio 1 u32 match ip dst 127.127.127.127 flowid 2:1 -# Create an interface alias call 'lo:benchmark' that maps 127.127.127.127 to loopback -sudo ip addr add dev lo 127.127.127.127/32 label lo:benchmark -``` - -to remove this configuration - -```sh -sudo tc qdisc del dev lo root -sudo ip addr del dev lo 127.127.127.127/32 label lo:benchmark -``` - -Other Platforms -=============== - -Contributions welcome! -