<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Benchmark on BLAZED.sh Blog</title>
    <link>https://blazed.sh/blog/tags/benchmark/</link>
    <description>Recent content in Benchmark on BLAZED.sh Blog</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 01 Aug 2026 14:00:00 +0000</lastBuildDate>
    <atom:link href="https://blazed.sh/blog/tags/benchmark/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Ethereum RPC Latency in 2026: IPC vs WebSocket vs Remote Providers, Measured</title>
      <link>https://blazed.sh/blog/posts/ethereum-rpc-latency-benchmark/</link>
      <pubDate>Sat, 01 Aug 2026 14:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/ethereum-rpc-latency-benchmark/</guid>
      <description>&lt;p&gt;Every RPC provider sells latency and almost nobody publishes a distribution. You get a marketing average, occasionally a p95 on a status page, and never the methodology. We wrote a &lt;a href=&#34;https://blazed.sh/blog/posts/ipc-vs-http-websocket-ethereum-rpc&#34;&gt;transport comparison&lt;/a&gt; last June that leaned on illustrative ranges because we had not measured them ourselves, and that has bothered us since. So this post measures instead: nine public Ethereum endpoints, up to 300 samples each, percentiles rather than means, a race between three subscription feeds to see who learns about a new block first, and a separate benchmark of what a JSON-RPC round-trip costs when there is no network in the path at all.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
