Merge remote-tracking branch 'origin/topic/neverlord/restore-routing-…

…table-benchmark'

* origin/topic/neverlord/restore-routing-table-benchmark:
  Restore the routing-table benchmark program

CHANGES

@@ -1,3 +1,7 @@
+2.8.0-dev.55 | 2024-03-19 15:30:46 -0700
+
+  * Restore the routing-table benchmark program (Dominik Charousset, Corelight)
+
 2.8.0-dev.53 | 2024-03-19 15:30:10 -0700
 
   * Restore python-ssl test (Dominik Charousset, Corelight)

VERSION

@@ -1 +1 @@
-2.8.0-dev.53
+2.8.0-dev.55

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)

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.

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_path_type> 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<endpoint_id>;
 
 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<value_type>::max()};
-    array_type result;
-    for (auto& x : result)
-      x = static_cast<value_type>(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<std::byte>(d(rng));
+    return broker::endpoint_id(bytes);
   }
 
   std::minstd_rand rng;