<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Felix blog: performance</title>
    <link>https://getfelix.dev/topics/performance/</link>
    <description>Felix blog posts about performance.</description>
    <language>en</language>
    <atom:link href="https://getfelix.dev/topics/performance/feed.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Even overall, lopsided per stream</title>
      <link>https://getfelix.dev/blog/even-overall-lopsided.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/even-overall-lopsided.html</guid>
      <pubDate>Fri, 23 Oct 2026 00:00:00 +0000</pubDate>
      <description>Felix placement kept every broker&#39;s leader count near the cluster-wide share, and a single stream could still land 1/1/10 with all its writes on one broker; this is how placement now spreads each stream&#39;s leaders too.</description>
    </item>
    <item>
      <title>Fast, without losing messages</title>
      <link>https://getfelix.dev/blog/fast-without-losing-messages.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/fast-without-losing-messages.html</guid>
      <pubDate>Fri, 23 Oct 2026 00:00:00 +0000</pubDate>
      <description>How Felix answers a fsynced publish in a third of a millisecond, writes at the disk&#39;s full rate under load, and slows publishers down instead of dropping their messages.</description>
    </item>
    <item>
      <title>How we catch a 1% regression</title>
      <link>https://getfelix.dev/blog/catching-a-one-percent-regression.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/catching-a-one-percent-regression.html</guid>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <description>Felix&#39;s rule is that a release must not be measurably slower than the one before it; this is how same-runner A/B runs, a Welch&#39;s t-test and throwaway bisect PRs in GitHub Actions find a 1-2% loss, and why a single benchmark run can&#39;t.</description>
    </item>
    <item>
      <title>One slow subscriber shouldn&#39;t slow anyone else</title>
      <link>https://getfelix.dev/blog/one-slow-subscriber.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/one-slow-subscriber.html</guid>
      <pubDate>Fri, 16 Oct 2026 00:00:00 +0000</pubDate>
      <description>How Felix keeps one slow subscriber from holding up publishers or other readers, and how a 2% single-publisher loss came from where the feeder gave back a subscriber&#39;s byte budget.</description>
    </item>
    <item>
      <title>Ten parcels, one envelope: Linux UDP GSO and Felix&#39;s MTU cap</title>
      <link>https://getfelix.dev/blog/ten-parcels-one-envelope.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/ten-parcels-one-envelope.html</guid>
      <pubDate>Sun, 27 Sep 2026 00:00:00 +0000</pubDate>
      <description>Raising Felix&#39;s QUIC MTU on Linux stalled delivery for good, because UDP GSO turns ten packets into one datagram the kernel refuses and quinn never falls back; this is how we found it, why the cap is 6,550, and why 4,096 is the default.</description>
    </item>
  </channel>
</rss>
