RDRS Demo Control

This benchmark setup uses 1 benchmark node, 1 RDRS (RonDB REST Server) node and 2 data nodes. There is also a MySQL Server used to create the databases and tables.

When you create a database, you get a test table with 100'000 rows and 10 columns. By default, each REST request fetches 100 rows, with 1000 values in total.

REST requests are handled as follows:

1. The benchmark client sends a REST request to RDRS, containing several key lookup requests.
2. RDRS forwards the key lookup requests to the RonDB data nodes.
3. Data nodes process the request and send the responses back to RDRS.
4. RDRS compiles the key lookup results into one REST response, which is sent back to the benchmark client.

Each network jump induces a delay of about 250-280 μs (ping latency is between 500-560 μs). Thus between 1.0-1.1 milliseconds latency is due to network latency. The remainder of the latency is spent in RDRS, RonDB data nodes and the Python client.

The reported benchmark with 100M Key lookups on our front page used a setup with network latency around 130 μs.

This test cluster is running on 3 dedicated servers, each with an AMD Ryzen 7 7700 8-Core Processor and 64 GiB RAM. The data, RDRS and bench nodes run as VMs, distributed such that each network jump needs to go to a different physical machine, in order to incur a realistic latency.

Do you want to run a bigger benchmark? Use this open source tool to create a cluster just like this one – except no limits.