<?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>성능측정 on Simon의 AI 시대에 살아남는 법</title><link>https://mhub.uk/tags/%EC%84%B1%EB%8A%A5%EC%B8%A1%EC%A0%95/</link><description>Recent content in 성능측정 on Simon의 AI 시대에 살아남는 법</description><generator>Hugo</generator><language>ko-KR</language><copyright>2026 mhub. 이 블로그의 모든 글·그림과 전자책(그림으로 배우는 시리즈)의 저작권은 mhub에 있으며, 저작권자의 허락 없는 무단 복제·배포·전재를 금지합니다. 이용 허락이나 오류 제보는 문의하기로 보내 주세요.</copyright><lastBuildDate>Sat, 07 Nov 2026 19:15:00 +0900</lastBuildDate><atom:link href="https://mhub.uk/tags/%EC%84%B1%EB%8A%A5%EC%B8%A1%EC%A0%95/index.xml" rel="self" type="application/rss+xml"/><item><title>DNS가 두 번 속였다 — TTFB 5.7초 오진과 A+AAAA 동시 조회 5.2초 스톨</title><link>https://mhub.uk/posts/ops-05-dns-lied-twice-ttfb-and-aaaa-stall/</link><pubDate>Sat, 07 Nov 2026 19:15:00 +0900</pubDate><guid>https://mhub.uk/posts/ops-05-dns-lied-twice-ttfb-and-aaaa-stall/</guid><description>&lt;p&gt;&amp;lsquo;폰 서버 안정화 일지&amp;rsquo; 다섯 번째 글이다. 느린 건 서버가 아니라 측정기였다는 걸 두 번이나 겪었다. 한 번은 블로그 성능 진단에서, 한 번은 메인 터널 감시에서. 둘 다 범인은 DNS였다.&lt;/p&gt;
&lt;h2 id="사건-1-ttfb-57초라는-위기"&gt;사건 1: TTFB 5.7초라는 위기&lt;/h2&gt;
&lt;p&gt;블로그 SEO 점검을 하다가 첫 바이트 도착 시간(TTFB)을 재 보니 5.6~5.8초가 나왔다. 검색엔진이 싫어할 숫자다. 서버 자체는 폰 안에서 직접 치면 20~80ms로 빨랐으니, 터널 구간을 의심했다. 실제로 cloudflared 로그엔 &lt;code&gt;timeout: no recent network activity&lt;/code&gt;라는 QUIC 재연결 폭풍이 찍혀 있었고, 그걸 근거로 &amp;ldquo;터널이 느리다&amp;quot;고 결론 내렸다. 이 cloudflared 버전은 전송 프로토콜을 고르는 옵션이 제거돼 있어 설정으로 고칠 길이 없었고, 대안으로 Cloudflare Cache Rule을 만들어 엣지 캐시를 켰다.&lt;/p&gt;</description></item></channel></rss>