Tarragon

"Performance"

• 2026-05-12 9.1 壓測理論與系統行為 Little's Law、queueing theory、USL、saturation curve 在容量規劃中的角色
• 2026-05-12 9.C1 AWS Prime Day 2025：可預期極端峰值的 dogfood Amazon 自家服務在 Prime Day 2025 的峰值數字 — 一年一次可預期峰值的容量設計參考
• 2026-05-12 Active Parameter MoE 模型每生成一個 token 實際參與計算的參數量、跟模型總參數量不同、影響推論速度上限
• 2026-05-12 Flash Attention Attention 計算的記憶體友善實作、減少 GPU memory 讀寫、提升長 context 推論吞吐
• 2026-05-11 0.1 為什麼 LLM 生字慢 自回歸架構與記憶體頻寬瓶頸：為何即使 Mac 算力很強，本地 LLM 仍一個字一個字吐
• 2026-06-19 Sentry 深入 Error tracking + performance monitoring + session replay 的架構 — Sentry 從 error-first 出發如何擴展到全面可觀測性
• 2026-05-12 9.2 Workload Modeling 把 production traffic shape 翻成可重播的壓測模型
• 2026-05-12 9.C2 GR8 Tech：AI 預測式自動擴容下的體育博彩高峰 AI 預測 + EKS 自動擴容怎麼在 25ms p95 下承載 54000 TPS 體育博彩峰值流量
• 2026-05-12 9.3 壓測工具選型 k6 / JMeter / Gatling / Locust / Vegeta / Production Replay 的工程選型
• 2026-05-12 9.C3 Coinbase International Exchange：超低延遲交易的逆向容量設計 為什麼 Coinbase 國際交易所選 Cluster Placement Group + z1d 而不是自動擴容 — 延遲敏感型負載的容量取捨
• 2026-05-12 9.4 Saturation Discovery 找出 throughput plateau 與 latency knee 的方法
• 2026-05-12 9.C4 DraftKings：Aurora 撐 100 萬 ops/min 的體育博彩金融帳本 DraftKings 用 Aurora MySQL 跑體育博彩金融帳本、Super Bowl 流量 +50% 不影響延遲
• 2026-04-22 4.4 sync.RWMutex：保護共享狀態 用讀寫鎖保護共享狀態
• 2026-01-20 4.4 單例與快取模式 控制物件生命週期
• 2026-05-12 9.5 瓶頸定位流程 從 app 到 DB / cache / broker / 第三方 quota 的逐層瓶頸定位
• 2026-05-12 9.C5 Amazon Ads：DynamoDB 9000 萬 reads/sec 的廣告事件量測 Amazon Ads 在 DynamoDB 上跑 9000 萬 reads/sec + 500 萬 writes/sec、99.999% 可用性的廣告事件量測
• 2026-04-23 4.5 高併發控制與 backpressure 用 bounded concurrency、backpressure 與 cancellation 控制 goroutine 的成長
• 2026-05-12 9.6 容量規劃模型 peak forecast、headroom budget、growth curve、autoscaling sizing
• 2026-05-12 9.C6 Tinder：ElastiCache for Valkey 撐 4700 萬月活的配對引擎 Tinder 用 Amazon ElastiCache for Valkey 提供配對引擎所需的次毫秒延遲快取層
• 2026-05-12 9.7 成本邊界與 efficiency cost per request、cost curve、降級成本、over-provisioning trade-off
• 2026-05-12 9.C7 Lyft：100+ 微服務在 8 倍峰值下的 Auto Scaling Lyft 用 AWS Auto Scaling 跨 100+ 個微服務承載 8 倍峰值流量、跨 200+ 城市
• 2026-04-23 5.7 錯誤處理與測試在高併發服務中的角色 把錯誤路徑、測試保護與並發行為放進服務可靠性觀點
• 2026-01-20 3.7 並行處理 - threading、multiprocessing、concurrent.futures Python 並行處理的三種方式與選擇指南
• 2026-05-12 9.8 效能可觀測性 saturation metric、USE / RED method、cost dashboard
• 2026-05-12 9.C8 Niantic Pokémon GO：在 GCP 上承載 50 倍突發流量 Pokémon GO 上線時實際流量達原始預估 50 倍、Google CRE 怎麼即時補容量
• 2026-04-23 6.8 高併發下的 Redis 與 SQL 使用原則 從 Go 服務角度整理 Redis 與 SQL 的高併發存取邊界
• 2026-01-20 3.8 效能迷思與優化策略 Python 效能的真相、常見誤解與優化方法
• 2026-05-12 9.9 Performance Improvement Loop 壓測 → profile → fix → re-test → release gate 的閉環
• 2026-05-12 9.C9 Spotify：從自管 Kafka 遷移到 GCP Pub/Sub 的事件交付系統 Spotify 把自管 Kafka 事件系統遷移到 Google Cloud Pub/Sub、避免自管 broker 的容量規劃成本
• 2026-05-12 9.10 Production-Side 驗證 shadow traffic、dark launch、canary、production-like load test
• 2026-05-12 9.C10 Cloud Spanner：每秒 10 億請求的全球一致性資料庫 Google Cloud Spanner 內部峰值 10 億 req/sec、跨地區強一致 — 全球分散式 OLTP 容量參考
• 2026-06-20 Rate Limit 實作 單機 middleware / Redis 分散式限速 / 配額設計 — 概念見 DevOps 流量管控，本章聚焦後端實作
• 2026-05-12 9.11 高峰事件準備 活動、季節性流量、推廣事件的 capacity readiness 流程
• 2026-05-12 9.C11 Minecraft Earth：Azure Cosmos DB 上的全球分散式 AR 遊戲 Minecraft Earth 用 Cosmos DB 跨地區分散、測試到 100 萬 RU/s 仍維持承諾延遲
• 2026-06-20 SQLite Backend 效能基準 寫入吞吐 / 查詢延遲 / 資源消耗的量化預期 — 不同硬體環境下 SQLite 能撐多少、邊界在哪、怎麼實測
• 2026-05-12 9.12 SLO 與 Performance Budget performance budget 跟 SLO / error budget 的對接
• 2026-05-12 9.C12 Riot Games：246 個 EKS cluster 的多遊戲多地區治理 Riot Games 從 Mesos 遷移到 EKS、用 246 個 cluster 跨遊戲跨地區治理、年省 1000 萬美金
• 2026-05-27 9.13 擴展軸與 Stateless 前提 整理垂直 / 水平擴展取捨、stateless vs stateful 前提、auto scaling 操作模型與兩種擴展的 hidden cost
• 2026-05-12 9.C13 Disney+ Hotstar：IPL 板球決賽 1860 萬人同時直播 Hotstar 在 IPL 板球決賽創下 1860 萬同時觀看的全球直播紀錄、CDN 與全球邊緣容量極限
• 2026-05-27 9.14 連線池放大解法（PgBouncer / RDS Proxy / ProxySQL） 水平擴展應用層時 DB 連線池放大問題的具體解法、connection pooler 三大選項對比、解 9.13 提出但未深入的隱性成本
• 2026-05-12 9.C14 Standard Chartered：受監管銀行的 Aurora 4000 TPS 容量提升 Standard Chartered 銀行遷移到 Aurora 後吞吐量提升 10 倍至 4000 TPS、跨 7 個受監管市場
• 2026-05-12 9.C15 拓元 Tixcraft：售票搶購的瞬間爆量架構 拓元用 DynamoDB 當寫入緩衝 + 傳統伺服器當慢速消費者、承受 100K+ 同時選位 + 30 秒從 6 台擴到 800 台
• 2026-05-19 MySQL InnoDB Tuning：為什麼一個 100 GB DB 在 64 GB RAM server 上 query 慢 5 倍 InnoDB 是 MySQL 預設 storage engine、預設值給 256 MB buffer pool（早期 default）。本文從一個常見痛點開場（DB > RAM 但 server 仍 swap）、走 4 個 critical knob（buffer pool / redo log / flush method / IO capacity）、各自如何影響讀寫吞吐、配置 step-by-step、5 production 踩雷（buffer pool warm-up / log file 大小 / 設 sync_binlog=0 換速度 / IO scheduler / undo log 膨脹）、跟 SSD / NVMe / EBS 的 IO 假設
• 2026-05-12 9.C16 SeatGeek：DynamoDB + Lambda 打造的虛擬等候室 SeatGeek 用 DynamoDB 4 張表 + Lambda Bouncer 實作 flash-sale 限流排隊機制、取代第三方 waiting room 服務
• 2026-05-12 9.C17 BookMyShow：印度年售 2 億張票的資料架構現代化 BookMyShow 從 15 年自建 analytics 遷移到 AWS modern data architecture、4 個月完成、分析成本下降 80%
• 2026-05-12 9.C18 Zoom：COVID 期間從 1000 萬到 3 億 DAU 的 30 倍突發 Zoom 在 2020 年 COVID 爆發時、日活從 1000 萬衝到 3 億、用 DynamoDB 撐住會議後端
• 2026-05-12 9.C19 Capcom：Resident Evil / Monster Hunter 在 DynamoDB + EKS 上的遊戲後端 Capcom 把 Resident Evil、Street Fighter、Monster Hunter 遊戲後端跑在 DynamoDB + EKS、單一秒位數延遲、營運成本降 30%
• 2026-05-12 9.C20 Zomato：從 TiDB 遷移到 DynamoDB、吞吐 4 倍、延遲降 90%、成本減 50% Zomato 帳單系統從 TiDB 遷移到 DynamoDB、吞吐 2K→8K RPM、延遲降 90%、成本減 50%
• 2026-05-12 9.C21 ASOS：Cosmos DB 在 Black Friday 撐 1.67 億請求 ASOS 在 2016 Black Friday 用 Azure Cosmos DB 撐 24 小時 1.67 億請求、3500 req/sec、48ms 平均延遲
• 2026-05-12 9.C22 Wayfair：用 GCP 提供 Way Day / Black Friday 的 burst capacity Wayfair 22M+ 商品 + 16,000+ 供應商、用 GCP 補充 on-prem data center 在峰值事件的 burst capacity
• 2026-05-12 9.C23 Netflix：把關聯式 DB 統一到 Aurora、效能 +75%、成本 -28% Netflix 把多套關聯式 DB 統一到 Aurora、效能提升 75%、成本下降 28%、串流數十億小時
• 2026-05-12 9.C24 Genesys：用 DynamoDB 在 15 region 跑出 99.999% 可用性 Genesys 客服平台用 DynamoDB 為預設資料層、跨 15 主 region + 5 衛星 region、達成 12 個月 99.999% 可用性
• 2026-05-12 9.C25 Tubi：從 ScyllaDB 遷到 ElastiCache、ML feature store 達 sub-10ms p99 Tubi 把 ML 推薦的 feature store 從 ScyllaDB 遷到 ElastiCache for Redis、99 百分位延遲降到 10ms 以下
• 2026-05-12 9.C26 PayPay：行動支付每日 3 億訊息的 DynamoDB 後端 日本最大行動支付 PayPay 每日 3 億訊息、用 DynamoDB 處理通知與訊息功能、支撐次秒級反應
• 2026-05-12 9.C27 Disney+：DynamoDB 撐每日數十億動作的觀看歷史 Disney+ 用 DynamoDB 撐每日數十億動作的觀看歷史、watchlist、播放進度等串流 metadata
• 2026-05-12 9.C28 FanDuel：體育直播 + 投注的雙重峰值 FanDuel 3.5M MAU、Super Bowl 期間擴容 5-10 倍、用 AWS Local Zones + Wavelength + Outposts 處理 20+ 州的雙重峰值
• 2026-05-12 9.C29 NTT DOCOMO Lemino：3 個月達 500 萬 MAU 的串流後端 Lemino 用 DynamoDB + AWS Media Services 撐 30 channels live + 5M MAU、工程工時下降 90%
• 2026-05-12 9.C30 Microsoft 365：從 MongoDB 遷移到 Cosmos DB 的分析平台 Microsoft 365 把使用分析平台從 MongoDB 遷移到 Cosmos DB、planet-scale 全球分散式分析
• 2026-05-12 9.C31 Mercado Libre：LatAm 電商在 GCP 上用 Vertex AI 搜尋 1.5 億商品 Mercado Libre 1 億客戶 + 1.5 億商品、用 GCP Vertex AI Search + BigQuery 提供近即時搜尋與分析
• 2026-05-18 PostgreSQL autovacuum tuning：為什麼你的 autovacuum 永遠追不上 bloat MVCC 怎麼產生 dead tuple、autovacuum cost-based throttle 為什麼預設保守、per-table tuning 怎麼設、5 個 production 踩雷（cost_limit 太低 / 長 transaction blocks vacuum / anti-wraparound 在 peak / partition vacuum 滿 worker / index bloat 沒處理）、跟 partitioning + monitoring 整合
• 2026-05-13 9.C32 Clearent：Azure SQL Hyperscale 撐每年 5 億筆支付交易 Clearent 在 Azure SQL Hyperscale 上處理每年 5 億筆支付交易、autoscale + 微服務架構
• 2026-05-18 PostgreSQL declarative partitioning：partition 不是切表、是讓 planner pruning Declarative partitioning 的真實價值是 query planner pruning + maintenance scope 縮小、不是「把大表切小」；RANGE / LIST / HASH 取捨、partition key 選法、5 個 production 踩雷（key 選錯不 prune / unique 不 enforce 跨 partition / ATTACH 鎖太久 / partition 數爆 / DETACH 不 reclaim 空間）、跟 autovacuum + index 設計整合
• 2026-05-13 9.C33 Maersk + Bosch：傳統產業在 Azure AKS 上的微服務治理 全球海運 Maersk 跟 Bosch 智慧建築把 AKS 當微服務治理基礎、釋放工程資源做業務功能
• 2026-04-25 Reactive 監聽器的效能 audit：跨 listener 類型盤點觸發頻率 MutationObserver / ResizeObserver / event listener 各自的觸發頻率怎麼盤點。本文是效能 audit 視角 — 找問題用、跟 #29 (observer 設計指引) 互補不重複。
• 2026-05-13 9.C34 GCP：130,000-node GKE cluster 的工程極限 Google 用單一 GKE control plane 跑 13 萬個 node、AI workload + 1000 Pods/sec 創建吞吐
• 2026-04-25 Runtime 計算成本：每筆迭代與正則 Scope filter 對每筆結果跑 regex — 結果數量大時成為 frame budget 的主要消耗。本文盤點此類「每筆迭代 + per-item 計算」的風險點與評估方法。
• 2026-05-13 9.C35 Snap：GCP + KeyDB 在 multi-cloud 架構下的低延遲快取 Snap 用 GCP 上的 KeyDB cluster 減少跨 cloud cache 延遲、用 TPU 訓練廣告推薦模型
• 2026-04-25 Layout reflow / repaint 的可量化評估 Filter slot 切換、CSS 變數寫入、絕對定位重算 — 哪些操作觸發 reflow 而非僅 repaint、用什麼工具量、評估值落在哪個區間值得優化。
• 2026-05-26 9.C36 Coinbase：MongoDB 撐 Ruby 單體 + 1.5M reads/sec identity 服務 Coinbase 以 MongoDB 為主資料層、自建 mongobetween connection proxy、users 服務在加密貨幣 surge 時撐 1.5M reads/sec
• 2026-04-25 資源載入時序：lazy chunk 與 critical path Pagefind 的 index 採 chunked lazy load — 首次互動延遲與 critical path 之間的取捨怎麼盤點。預載 entry chunk 的時機與不預載的代價。
• 2026-05-26 9.C37 Forbes：自管 MongoDB → Atlas on GCP、build 時間 25 → 9 分鐘 Forbes 把自管 MongoDB 遷到 Atlas on Google Cloud、6 個月完成、build 25 → 9 分鐘、120M 不重複訪客單月承接
• 2026-05-26 9.C38 Toyota Connected：MongoDB Atlas 撐 900 萬車輛 telematics、月 180 億 transaction Toyota Connected 用 MongoDB Atlas 撐 Safety Connect 900 萬車、月 180 億 transaction、緊急訊號 3 秒內到 agent
• 2026-05-26 9.C39 DoorDash：Aurora Postgres 寫入瓶頸 → CockroachDB 多主寫入 DoorDash 從 Aurora Postgres 遷到 CockroachDB、解 1.6 M QPS 單主寫入瓶頸、外送平台爆量壓力下重做 OLTP 拓樸
• 2026-05-26 9.C40 Netflix：380+ CockroachDB cluster 的 multi-active 拓樸艦隊 Netflix 把 Cassandra 不夠用的 transactional workload 移到 CockroachDB、380+ cluster / 60+ 跨 region、含 Open Connect、studio cloud drive、gaming control plane
• 2026-05-26 9.C41 Hard Rock Digital：CockroachDB on AWS Outposts、Wire Act 合規 + 跨州單一邏輯 DB Hard Rock Digital 用 CockroachDB 跨 AWS Outposts + US-East-1、Wire Act 強制資料留州、單一邏輯 DB 解多州 sportsbook、100 node 32 vCPU 撐 Super Bowl
• 2026-04-26 Build-time 預處理 vs Runtime 計算的光譜：何時把成本前置 計算可放 build-time（預處理一次、runtime 0）或 runtime（per query 算）— 兩極之間有 hybrid 段（hot path 預算、cold path runtime）。判準四軸：query 頻率 / dataset 大小 / freshness 需求 / build pipeline 複雜度。Build-time 不是「永遠較好」、freshness / 多樣性高時 runtime 反而對。本卡把 #59 五策略中「query-side pushdown vs client-side fallback」的取捨抽象化、跨領域適用。
• 2026-04-26 Dataset 規模改變什麼可行：「需要 index」依 scale 而定 工程師習慣以「production scale」為預設、自動假設「O(N) scan 不可行、需要 index」。但小 dataset 內、O(N) 甚至 O(N²) 都 trivial、不該過度工程。本卡列具體 threshold（< 1MB / < 10MB / < 100MB / > 1GB）對應的可行操作、跟「猜測 production scale 過度設計」的反模式對照。本卡是 #43 最小必要範圍在「規模假設」維度的展現。
• 2026-05-22 MySQL Cross-buffer Memory Contention MySQL InnoDB buffer pool、sort / join buffer、tmp table、thread memory、OS page cache 與 memory pressure 判讀
• 2026-05-21 SQLite PRAGMA Tuning and Performance SQLite journal_mode、synchronous、busy_timeout、wal_autocheckpoint、cache_size、mmap_size、auto_vacuum 與 performance evidence 的操作判準
• 2026-05-19 JMeter → k6：k6 不是 JMeter 的「script 版本」、是 VU model 取代 thread model JMeter → k6 是 Type E paradigm shift、不是把 .jmx XML 翻成 JavaScript — VU (virtual user) model 跟 thread group model 是兩種對「使用者行為」不同的建模方式。本文走 6 維 audit（Schema High / Paradigm High / Operational Medium）、釐清反向定義、4-phase partial migration（多數 org 停 Phase 2-3 hybrid）、5 production 踩雷（thread group 翻譯失真 / arrival rate vs concurrent VU 混淆 / protocol gap / 結果 schema 改 / CI integration 重做）、protocol gap（JDBC / JMS / LDAP 在 k6 沒原生對應）、何時不要切
• 2026-05-19 Pyroscope → Datadog Continuous Profiler：profiling deployment lifecycle 各階段 operational ownership 轉手 Pyroscope → Datadog Continuous Profiler 是 Type C operational hybrid migration — pprof data model 接近、profile lifecycle 五階段（install / instrument / ingest / query / cost）的 ops ownership 從 self-host 轉到 SaaS。本文走 6 維 audit（Operational High 其他 Low）、4-phase migration（operational audit + agent parallel + tag reconcile + cutover）、5 production 踩雷（agent 重複 overhead / tag schema 不一致 / trace_id correlation 斷 / cost 突增 / retention 政策變動）、何時保留 Pyroscope（資料主權 / 內網 / OSS-first / cost sensitive）
• 2026-04-26 Reactive Performance — Reactive 效能盤點與優化 frontend-with-playwright reference：MutationObserver 三維度、polling → observer、iteration / regex 成本、layout reflow、resource 載入時序、reactive listener 盤點協議。