From 33a995dfd2bd26f11aea828aba96ba5966177d9d Mon Sep 17 00:00:00 2001 From: Lorenzo Cogotti Date: Wed, 20 Oct 2021 04:08:25 +0200 Subject: [PATCH] [blog/bgpgrep-performance-facts] Few fixes and improvements --- content/blog/bgpgrep-performance-facts.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/blog/bgpgrep-performance-facts.md b/content/blog/bgpgrep-performance-facts.md index 209fae2..642b7ce 100644 --- a/content/blog/bgpgrep-performance-facts.md +++ b/content/blog/bgpgrep-performance-facts.md @@ -49,7 +49,7 @@ after one warmup round. MRT data is decompressed upfront, to avoid accounting fo decompression overhead, the output is sent directly to `/dev/null`, to avoid any disk write overhead. -## The show's on +## Let the fun begin! We take the data for the first benchmark from RouteViews' [Sydney Route Collector](http://archive.routeviews.org/route-views.sydney/bgpdata), and pull the very first RIB of December 2020, along with any subsequent updates from the same month. @@ -71,7 +71,7 @@ bgpdump -mv sydney/2020-12/uncompressed.mrt >/dev/null `bgpgrep` is 11% faster than `bgpscanner`, which is good. Since this benchmark operates mostly on MRT update dumps, let's try the same on a different dataset, mostly made of RIBs. -We pull nine RIBs from RIPE RIS NCC [RRC00 Route Collector]](https://data.ris.ripe.net/rrc00/2019.12/), +We pull nine RIBs from RIPE RIS NCC [RRC00 Route Collector](https://data.ris.ripe.net/rrc00/2019.12/), and obtain 25.7GB worth of uncompressed MRT data. This time the benchmark is limited to `bgpgrep` and `bgpscanner`.