From 66785067df98bae20e60c8de3d242b2a7cfe6755 Mon Sep 17 00:00:00 2001 From: Dominik Charousset Date: Sun, 17 Mar 2024 13:56:56 +0100 Subject: [PATCH] Restore the routing-table benchmark program --- tests/benchmarks/CMakeLists.txt | 2 +- tests/benchmarks/routing-table/README.md | 26 +++++++++++++++++++ .../benchmarks/routing-table/routing-table.cc | 21 +++++---------- 3 files changed, 33 insertions(+), 16 deletions(-) create mode 100644 tests/benchmarks/routing-table/README.md diff --git a/tests/benchmarks/CMakeLists.txt b/tests/benchmarks/CMakeLists.txt index 9ba0f95f6..37add07df 100644 --- a/tests/benchmarks/CMakeLists.txt +++ b/tests/benchmarks/CMakeLists.txt @@ -2,5 +2,5 @@ find_package(benchmark QUIET) # add_subdirectory(cluster) add_subdirectory(fan-out) -# add_subdirectory(routing-table) +add_subdirectory(routing-table) # add_subdirectory(serialization) diff --git a/tests/benchmarks/routing-table/README.md b/tests/benchmarks/routing-table/README.md new file mode 100644 index 000000000..3faabeaa2 --- /dev/null +++ b/tests/benchmarks/routing-table/README.md @@ -0,0 +1,26 @@ +The `broker-routing-table-benchmark` program is a standalone, self-contained +tool to compare the performance of different routing table implementations. + +The routing table represents the central data structure in ALM-enabled Broker. +This data structure provides essential algorithms for the source routing as well +as for looking up shortest paths. Hence, the scalability of Broker naturally +depends on the data structures and algorithms used for representing routing +information. + +In order to measure performance and scalability of the central functionality, we +have implemented a new set of micro benchmarks for Broker. The main algorithms +that Broker calls frequently are: + +- `add_or_update_path`: this algorithm adds entries to the routing table or + updates the vector timestamp for a path. Called on each update Broker receives + from one of its peers. +- `shortest_path`: frequently called for retrieving a path to a single node. +- `generate_paths`: implements the source routing in Broker by converting a list + of receivers to a multipath. Basically calls shortest_path for all receivers + and merges the paths with shared hops into a single tree-like structure. +- `erase`: removes an entry from the routing table. Among the algorithms listed + here, this algorithm is called least frequently since Broker only calls it + when endpoints leave the overlay. + + The benchmark program exercises these algorithms with different workloads and + with different routing table implementations. diff --git a/tests/benchmarks/routing-table/routing-table.cc b/tests/benchmarks/routing-table/routing-table.cc index 3a2cec107..eae6c7e3d 100644 --- a/tests/benchmarks/routing-table/routing-table.cc +++ b/tests/benchmarks/routing-table/routing-table.cc @@ -20,8 +20,6 @@ struct linear_routing_table_row { endpoint_id id; - caf::actor hdl; - std::vector versioned_paths; linear_routing_table_row() = default; @@ -34,11 +32,6 @@ struct linear_routing_table_row { explicit linear_routing_table_row(endpoint_id id) : id(std::move(id)) { versioned_paths.reserve(32); } - - linear_routing_table_row(endpoint_id id, caf::actor hdl) - : id(std::move(id)), hdl(std::move(hdl)) { - versioned_paths.reserve(32); - } }; struct linear_routing_table { @@ -182,20 +175,18 @@ bool add_or_update_path(sorted_linear_routing_table& tbl, using path_type = std::vector; struct id_generator { - using array_type = caf::hashed_node_id::host_id_type; + using array_type = broker::endpoint_id::array_type; id_generator() : rng(0xB7E57) { // nop } endpoint_id next() { - using value_type = array_type::value_type; - std::uniform_int_distribution<> d{0, - std::numeric_limits::max()}; - array_type result; - for (auto& x : result) - x = static_cast(d(rng)); - return caf::make_node_id(d(rng), result); + std::uniform_int_distribution<> d{0, 255}; + array_type bytes; + for (auto& x : bytes) + x = static_cast(d(rng)); + return broker::endpoint_id(bytes); } std::minstd_rand rng;