kentonv / capnp-vs-ice

Quick RPC latency benchmark of Cap'n Proto RPC vs. Apache Thrift vs. ZeroC Ice

Dependent Calls: Cap'n Proto vs. Thrift vs. Ice

Note: Only tested on Linux, though "should" work on others.

This is a test/benchmark designed to demonstrate how promise pipelining can significantly reduce latency.

The test defines, using each framework, a server that exports a simple four-function calculator interface. The interface simply has methods add(), sub(), mult(), and div(), each taking two integers and returning an integer.

The client programs each attempt to use this interface to compute the following expression:

((5 * 2) + ((7 - 3) * 10)) / (6 - 4)

Notice that there are six arithmetic operations in the expression, but with parallelization we can complete it in four steps:

((5 * 2) + ((7 - 3) * 10)) / (6 - 4)
  (10    + (   4    * 10)) /    2
  (10    +         40)     /    2
        50                 /    2
                          25

Both Ice and Cap'n Proto easily support parallelization. Cap'n Proto uses promises, and Ice supports something future-like. Thrift is a little stranger in that its calls are FIFO, but for the purpose of this test that allows us to parallelize just as well as Ice.

The test measures the number of network round trips taken to complete the operation.

To run the test, first install Thrift, Ice and Cap'n Proto, then simply run:

./runtest.sh

As expected, Thrift and Ice take four round trips.

Cap'n Proto, however, takes only one round trip, due to promise pipelining.

To understand how this works, see the docs.

capnp-vs-ice's Issues

Port mismatch of ice server and client

hi, kentonv.

In ice-server.c++, the simple ice server listens on port 10000, while the simple ice client in ice-client.c++ tries to connect to an ice object proxy at port 9999. So this connection may be mismatched any way.

I changed either port and passed the test.

What about Batched Invocations

Hi, I wondering,
if you ever consider using Batched Invocations which supposed to reduce
round trip and therefore latency

Best regards
Ben