<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Mirror Acceleration on Margrop Blog</title>
    <link>https://blog.margrop.net/en/tag/mirror-acceleration/</link>
    <description>Recent content in Mirror Acceleration on Margrop Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <lastBuildDate>Sat, 13 Jun 2026 07:20:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/en/tag/mirror-acceleration/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>From 5m14s to 0.6s: How I Rebuilt My Docker Hub Mirror After Hitting Three Walls</title>
      <link>https://blog.margrop.net/en/post/docker-registry-mirror-rebuild-2026/</link>
      <pubDate>Sat, 13 Jun 2026 07:20:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/docker-registry-mirror-rebuild-2026/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;My home lab had a &lt;code&gt;registry:2&lt;/code&gt; pull-through cache fronting Docker Hub for years, and it was fine. Then one day pulling a 5 MB &lt;code&gt;alpine:3.19&lt;/code&gt; took 5 minutes and 14 seconds. This post is the full forensic log of how I traced the slowdown, evaluated 8 candidate mirrors with real measurements (not vibes), and finished with a 5-line bash script on cron that &lt;strong&gt;auto-fails-over&lt;/strong&gt; when the primary mirror goes down. Every number in this article was captured on my own hardware, in my own network, at one specific moment in time.&lt;/p&gt;&#xA;&lt;p&gt;If you also self-host a Docker Hub mirror, or your team runs an internal registry, the Q&amp;amp;A at the bottom will probably save you 3 hours of pain.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
  </channel>
</rss>
