<?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>Benchmarking on Brave New Geek</title><link>https://bravenewgeek.com/category/benchmarking/</link><description>Recent content in Benchmarking 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/category/benchmarking/index.xml" rel="self" type="application/rss+xml"/><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>So You Wanna Go Fast?</title><link>https://bravenewgeek.com/so-you-wanna-go-fast/</link><pubDate>Wed, 24 Feb 2016 19:30:14 -0600</pubDate><guid>https://bravenewgeek.com/so-you-wanna-go-fast/</guid><description>&lt;p&gt;I originally proposed this as a &lt;a href="https://www.gophercon.com/"&gt;GopherCon&lt;/a&gt; talk on writing “high-performance Go”, which is why it may seem rambling, incoherent, and—at times—not at all related to Go. The talk was rejected (probably because of the rambling and incoherence), but I still think it’s a subject worth exploring. The good news is, since it was rejected, I can take this where I want. The remainder of this piece is mostly the outline of that talk with some parts filled in, some meandering stories which may or may not pertain to the topic, and some lessons learned along the way. I think it might make a good talk one day, but this will have to do for now.&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>Everything You Know About Latency Is Wrong</title><link>https://bravenewgeek.com/everything-you-know-about-latency-is-wrong/</link><pubDate>Sat, 12 Dec 2015 15:12:12 -0600</pubDate><guid>https://bravenewgeek.com/everything-you-know-about-latency-is-wrong/</guid><description>&lt;p&gt;Okay, maybe not &lt;em&gt;everything&lt;/em&gt; you know about latency is wrong. But now that I have your attention, we can talk about why the tools and methodologies you use to measure and reason about latency are likely horribly flawed. In fact, they’re not just flawed, they’re probably &lt;em&gt;lying to your face.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;When I went to &lt;a href="http://www.thestrangeloop.com/"&gt;Strange Loop&lt;/a&gt; in September, I attended a workshop called “Understanding Latency and Application Responsiveness” by Gil Tene. Gil is the CTO of Azul Systems, which is most renowned for its C4 pauseless garbage collector and associated Zing Java runtime. While the workshop was four and a half hours long, Gil also gave a 40-minute talk called &lt;a href="https://youtu.be/lJ8ydIuPFeU"&gt;“How NOT to Measure Latency”&lt;/a&gt; which was basically an abbreviated, less interactive version of the workshop. If you ever get the opportunity to see Gil speak or attend his workshop, I recommend you do. At the very least, do yourself a favor and watch one of his recorded talks or find his slide decks online.&lt;/p&gt;</description></item><item><title>Benchmark Responsibly</title><link>https://bravenewgeek.com/benchmark-responsibly/</link><pubDate>Fri, 02 Jan 2015 14:53:22 -0600</pubDate><guid>https://bravenewgeek.com/benchmark-responsibly/</guid><description>&lt;p&gt;When I posted my &lt;a href="http://www.bravenewgeek.com/dissecting-message-queues/"&gt;Dissecting Message Queues&lt;/a&gt; article last summer, it understandably caused some controversy.  I received both praise and scathing comments, emails asking why I didn’t benchmark X and pull requests to bump the numbers of Y. To be honest, that analysis was more of a brain dump from my own test driving of various message queues than any sort of authoritative or scientific study—it was &lt;em&gt;far&lt;/em&gt; from the latter, to say the least. The qualitative discussion was pretty innocuous, but the benchmarks and &lt;a href="https://github.com/tylertreat/mq-benchmarking"&gt;supporting code&lt;/a&gt; were the target of a lot of (valid) criticism. In retrospect, it was probably irresponsible to publish them, but I was young and naive back then; now I’m just mostly naive.&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>