1. Publish-Subscribe
2. FlatBuffers Publish-Subscribe
3. Request-Response
4. Event
5. Queue

The benchmark quantifies the latency between a Publisher sending a message and a Subscriber receiving it. In the setup, a bidirectional connection is established from process a to b (service name a2b) and back (service name b2a). Subscribers employ multithreaded busy waiting and promptly respond upon message reception. This process repeats n times, and the average latency is subsequently computed.

cargo run --bin benchmark-publish-subscribe --release -- --bench-all

For more benchmark configuration details, see

cargo run --bin benchmark-publish-subscribe --release -- --help

The benchmark quantifies the latency between a Publisher sending a FlatBuffer message and a Subscriber receiving it. The setup is identical to the Publish-Subscribe benchmark, but instead of a plain byte slice the payload is an unbounded FlatBuffer vector that is built with the FlatBuffers API directly inside the data segment of the Publisher. Every iteration serializes a complete FlatBuffer and acquires its root on the receiving side, therefore the measured latency also contains the serialization and deserialization cost.

cargo run --bin benchmark-publish-subscribe-flatbuffer --release -- --bench-all

For more benchmark configuration details, see

cargo run --bin benchmark-publish-subscribe-flatbuffer --release -- --help

The generated Rust code and the binary schema are already included in this benchmark. For completeness, the command used to generate them is documented below:

flatc -o benchmarks/publish-subscribe-flatbuffer/src --rust --schema --binary \
    benchmarks/publish-subscribe-flatbuffer/src/payload_data.fbs

The benchmark quantifies two scenarios:

1. The latency between a Client sending a request and a Server receiving it.
2. The latency of a response stream from an established request-response connection, i.e. sending a stream of responses from an ActiveRequest to the corresponding PendingResponse.

In the setup, a bidirectional connection is established from process a to b (service name a2b) and back (service name b2a). PendingResponses employ multithreaded busy waiting and promptly respond upon message reception. This process repeats n times, and the average latency is subsequently computed.

cargo run --bin benchmark-request-response --release

For more benchmark configuration details, see

cargo run --bin benchmark-request-response --release -- --help

The event quantifies the latency between a Notifier sending a notification and a Listener waking up from and responding to it. In the setup, a bidirectional connection is established from process a to b (service name a2b) and back (service name b2a). The Listener employs a blocking wait and wakes up on signal reception to promptly respond with a return signal notification. This process repeats n times, and the average latency is subsequently computed.

cargo run --bin benchmark-event --release -- --bench-all

For more benchmark configuration details, see

cargo run --bin benchmark-event --release -- --help

*     soft    nofile      4096
*     hard    nofile      8192

ulimit -n <new_limit>

The queue quantifies the latency between pushing an element into a queue and acquiring the element in another thread. In the setup, a bidirectional connection is established from process a to b (queue name queue_a2b) and back (queue name queue_b2a). The thread that acquires the queue's element employs a multithreaded busy waiting and promptly respond upon data retrieval. This process repeats n times, and the average latency is subsequently computed.

cargo run --bin benchmark-queue --release

For more benchmark configuration details, see

cargo run --bin benchmark-queue --release -- --help