From 627425e0fd2ec41c73821f5251d16a55a5018e46 Mon Sep 17 00:00:00 2001 From: Brett Kochendorfer Date: Tue, 19 Mar 2024 16:14:37 -0500 Subject: [PATCH] Update results-resp-bench.md (#42) Fix what I think is a typo Co-authored-by: Tal Zaccai --- website/docs/benchmarking/results-resp-bench.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/website/docs/benchmarking/results-resp-bench.md b/website/docs/benchmarking/results-resp-bench.md index 7f2c599f06..ec4e4fa655 100644 --- a/website/docs/benchmarking/results-resp-bench.md +++ b/website/docs/benchmarking/results-resp-bench.md @@ -90,7 +90,7 @@ In contrast, our latency experiments were performed on an empty database and for For the experiment depicted in Figure 1., we used large batches of GET operations (4096 requests per batch) and small payloads (8-byte keys and values) to minimize network overhead. As we increase the number of client sesssions, we observe that **Garnet** exhibits better scalability than Redis or KeyDB. -Dragonfly exhibits similar scaling scharacteristics though only up to 16 threads. Note also, that DragonFly is a pure in-memory system. +Dragonfly exhibits similar scaling characteristics though only up to 16 threads. Note also, that DragonFly is a pure in-memory system. Overall, **Garnet**'s throughput relative to the other systems is consistently higher even when the database size (i.e., the number of distinct keys pre-loaded) is larger (at 256 million keys) than the size of the processor cache.
@@ -307,4 +307,4 @@ In fact, it does not require much to observe a noticeable difference in throughp | ![tpt-bitop-batchsize.png](../../static/img/benchmark/tpt-bitop-batchsize.png) | |:--:| -| Figure 11: Throughput (log-scale), for increasing batchsize by 64 client sessions on a DB with 1024 keys and 1MB payload. | \ No newline at end of file +| Figure 11: Throughput (log-scale), for increasing batchsize by 64 client sessions on a DB with 1024 keys and 1MB payload. |