<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Benchmarks on Brave New Geek</title><link>https://bravenewgeek.com/tag/benchmarks/</link><description>Recent content in Benchmarks on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 29 Oct 2020 15:05:18 -0500</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/benchmarks/index.xml" rel="self" type="application/rss+xml"/><item><title>Fast Topic Matching</title><link>https://bravenewgeek.com/fast-topic-matching/</link><pubDate>Wed, 28 Dec 2016 17:52:30 -0600</pubDate><guid>https://bravenewgeek.com/fast-topic-matching/</guid><description>&lt;p&gt;A common problem in messaging middleware is that of efficiently matching message topics with interested subscribers. For example, assume we have a set of subscribers, numbered 1 to 3:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Subscriber&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Match Request&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;1&lt;/p&gt;
&lt;p&gt;forex.usd&lt;/p&gt;
&lt;p&gt;2&lt;/p&gt;
&lt;p&gt;forex.*&lt;/p&gt;
&lt;p&gt;3&lt;/p&gt;
&lt;p&gt;stock.nasdaq.msft&lt;/p&gt;
&lt;p&gt;And we have a stream of messages, numbered 1 to N:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Message&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Topic&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;1&lt;/p&gt;
&lt;p&gt;forex.gbp&lt;/p&gt;
&lt;p&gt;2&lt;/p&gt;
&lt;p&gt;stock.nyse.ibm&lt;/p&gt;
&lt;p&gt;3&lt;/p&gt;
&lt;p&gt;stock.nyse.ge&lt;/p&gt;
&lt;p&gt;4&lt;/p&gt;
&lt;p&gt;forex.eur&lt;/p&gt;
&lt;p&gt;5&lt;/p&gt;
&lt;p&gt;forex.usd&lt;/p&gt;
&lt;p&gt;…&lt;/p&gt;
&lt;p&gt;…&lt;/p&gt;
&lt;p&gt;N&lt;/p&gt;
&lt;p&gt;stock.nasdaq.msft&lt;/p&gt;
&lt;p&gt;We are then tasked with routing messages whose topics match the respective subscriber requests, where a “&lt;em&gt;*”&lt;/em&gt; wildcard matches any word. This is frequently a bottleneck for message-oriented middleware like ZeroMQ, RabbitMQ, ActiveMQ, TIBCO EMS, et al. Because of this, there are a number of &lt;a href="http://zeromq.org/whitepapers:message-matching"&gt;well-known&lt;/a&gt; &lt;a href="http://wso2.com/library/articles/2015/05/article-fast-topic-matching-algorithm-implementation-for-wso2-message-broker/"&gt;solutions&lt;/a&gt; &lt;a href="https://www.rabbitmq.com/blog/2010/09/14/very-fast-and-scalable-topic-routing-part-1/"&gt;to the problem&lt;/a&gt;. In this post, I’ll describe some of these solutions, as well as a novel one, and attempt to quantify them through benchmarking. As usual, the code is available &lt;a href="https://github.com/tylertreat/fast-topic-matching"&gt;on GitHub&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Benchmarking Commit Logs</title><link>https://bravenewgeek.com/benchmarking-commit-logs/</link><pubDate>Sun, 27 Nov 2016 13:28:55 -0600</pubDate><guid>https://bravenewgeek.com/benchmarking-commit-logs/</guid><description>&lt;p&gt;In this article, we look at &lt;a href="https://kafka.apache.org/"&gt;Apache Kafka&lt;/a&gt; and &lt;a href="http://nats.io/"&gt;NATS Streaming&lt;/a&gt;, two messaging systems based on the idea of a commit log. We’ll compare some of the features of both but spend less time talking about Kafka since by now it’s quite well known. Similar to &lt;a href="https://bravenewgeek.com/benchmarking-message-queue-latency/"&gt;previous&lt;/a&gt; &lt;a href="https://bravenewgeek.com/dissecting-message-queues/"&gt;studies&lt;/a&gt;, we’ll attempt to quantify their general performance characteristics through careful benchmarking.&lt;/p&gt;
&lt;p&gt;The purpose of this benchmark is to test drive the newly released NATS Streaming system, which was made generally available just in the last few months. NATS Streaming doesn’t yet support clustering, so we try to put its performance into context by looking at a similar configuration of Kafka.&lt;/p&gt;</description></item><item><title>Benchmarking Message Queue Latency</title><link>https://bravenewgeek.com/benchmarking-message-queue-latency/</link><pubDate>Sat, 13 Feb 2016 16:23:39 -0600</pubDate><guid>https://bravenewgeek.com/benchmarking-message-queue-latency/</guid><description>&lt;p&gt;About a year and a half ago, I published &lt;a href="https://bravenewgeek.com/dissecting-message-queues/"&gt;Dissecting Message Queues&lt;/a&gt;, which broke down a few different messaging systems and did some performance benchmarking. It was a naive attempt and had &lt;a href="https://bravenewgeek.com/benchmark-responsibly/"&gt;a lot of problems&lt;/a&gt;, but it was also my first time doing any kind of system benchmarking. It turns out benchmarking systems correctly is actually pretty difficult and many folks get it wrong. I don’t claim to have gotten it right, but over the past year and a half I’ve learned a lot, tried to build some better tools, and improve my methodology.&lt;/p&gt;</description></item><item><title>Dissecting Message Queues</title><link>https://bravenewgeek.com/dissecting-message-queues/</link><pubDate>Mon, 07 Jul 2014 00:33:53 -0500</pubDate><guid>https://bravenewgeek.com/dissecting-message-queues/</guid><description>&lt;p&gt;&lt;em&gt;&lt;strong&gt;Disclaimer (10/29/20)&lt;/strong&gt; – The benchmarks and performance analysis presented in this post should not be relied on. This post was written roughly six years ago, and at the time, was just the result of my exploration of various messaging systems. The benchmarks are not implemented in a meaningful way, which I discussed in a &lt;a href="https://bravenewgeek.com/benchmark-responsibly/"&gt;follow-up post&lt;/a&gt;. This post will remain for posterity and learning purposes, but I do not claim that this information is accurate or useful.&lt;/em&gt;&lt;/p&gt;</description></item></channel></rss>