Case #1: 以 Async/Await 管線化 Read/Process/Write，倍增大型檔案串流吞吐

Problem Statement（問題陳述）

業務場景：ASP.NET 後端需從 Azure Storage Blob 讀取約 100MB 影片，完成前端身份驗證後進行編碼處理並即時串流至瀏覽器。原實作以單一執行緒 while 迴圈順序執行 Read/Process/Write，導致整體吞吐量僅為直接由 Blob 下載的一半。監控顯示 CPU、網路皆未滿載，尖峰期用戶下載時間過長，影響觀影體驗與雲端節點成本。 技術挑戰：在不破壞輸出順序與記憶體足跡的前提下，將 I/O 與 CPU 工作用非同步重疊，避免各階段彼此阻塞。 影響範圍：單支 API 延遲×2、節點佔用時間拉長、單機併發能力降低、雲成本上升、SLA 風險上升。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 單執行緒順序執行：Read、Process、Write 逐段串行，互相等待。
2. 無非同步化：未採用 async/await，I/O 等待期間 CPU 閒置，Write 期間 Read/Process 停滯。
3. 輸出順序綁定：為確保輸出順序，整段被迫同步，錯失重疊空檔。

深層原因：

• 架構層面：管線為線性拓撲，無階段間重疊，無背壓/快慢相容機制。
• 技術層面：未採 Task-based Asynchronous Pattern（TAP），缺乏 await 邊讀邊寫的實作。
• 流程層面：缺少分階段量測（Stage Timing），誤判瓶頸。

Solution Design（解決方案設計）

解決策略：將 Write 改為非同步方法，並在迴圈中保存「上一輪 Write 的 Task」，每次開始新一輪 Read/Process 前僅等待上一輪 Write 完成；如此可在不破壞順序下重疊「本輪 Read+Process」與「上輪 Write」，最大化 I/O 與 CPU 併行度。

實施步驟：

1. 建立階段量測
   • 實作細節：以 Stopwatch 分別量測 Read/Process/Write 時間，輸出彙總。
   • 所需資源：System.Diagnostics.Stopwatch
   • 預估時間：0.5 小時
2. 改寫 Write 為 async/await
   • 實作細節：將 Write 改為 async Task，改用 await 非阻塞等待。
   • 所需資源：.NET 4.5+、C# 5.0
   • 預估時間：1 小時
3. 實作「一格前視」管線
   • 實作細節：在迴圈中保留上一輪 Write 的 Task，於下一輪開始前 await 之，再啟動新 Write。
   • 所需資源：Task/await、基本併行設計
   • 預估時間：1 小時
4. 驗證與壓測
   • 實作細節：固定資料量（例如 100MB）反覆測試，記錄前後耗時與 Mbps。
   • 所需資源：JMeter/k6 或自製壓測程式
   • 預估時間：1-2 小時

關鍵程式碼/設定：

// 關鍵：保留上一輪 Write 的 Task，僅在需要時 await，讓「本輪 Read+Process」與「上輪 Write」重疊
static Stopwatch readT = new(); static Stopwatch procT = new(); static Stopwatch writeT = new(); static Stopwatch allT = new();

static void Read(){ readT.Start(); Task.Delay(200).Wait(); readT.Stop(); }
static void Process(){ procT.Start(); Task.Delay(300).Wait(); procT.Stop(); }
static async Task Write(){ writeT.Start(); await Task.Delay(500); writeT.Stop(); }

static async Task DoWork(){
    Task prevWrite = null;
    for(int i=0;i<10;i++){
        Read();
        Process();
        if(prevWrite != null) await prevWrite; // 確保順序
        prevWrite = Write();                   // 啟動非同步寫出
    }
    if(prevWrite != null) await prevWrite;     // 等最後一筆
}

實際案例：從 Azure Blob 串流 100MB 影片，後端需做簡單編碼處理再輸出。原順序處理導致 Web 端約 3.5 Mbps，而直接向 Blob 拉取約 7.3 Mbps。 實作環境：.NET Framework 4.5、C# 5.0、IaaS VM + Azure Storage Blob 實測數據：

• 改善前：模擬 10 次迭代（200/300/500ms）總耗時約 10,000 ms
• 改善後：總耗時約 5,500~5,660 ms
• 改善幅度：時間縮短約 44%，吞吐提升約 1.8 倍

Learning Points（學習要點） 核心知識點：

• 使用 async/await 實作一格前視（look-ahead）管線
• 非同步 I/O 疊加 CPU 工作以提升資源利用
• 在保持輸出順序前提下做階段重疊

技能要求：

• 必備技能：C# TAP、Stopwatch 量測、基本 I/O 管線觀念
• 進階技能：負載測試、效能分析與競態條件避免

延伸思考：

• 可應用於串流媒體、報表匯出、檔案中繼轉送
• 限制：Read+Process 與 Write 時長差距過大時，重疊效益下降
• 進一步優化：雙緩衝、動態調整 chunk 大小與等待策略

Practice Exercise（練習題）

• 基礎練習：將提供的同步程式改成上述一格前視的 async 管線（30 分鐘）
• 進階練習：將 Write 改為實際 FileStream.WriteAsync，觀察硬碟 I/O（2 小時）
• 專案練習：從任意來源串流 500MB 檔案，加入簡單 CPU 處理，完成端到端壓測（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：正確輸出且順序無誤
• 程式碼品質（30%）：非同步用法正確、可讀性佳
• 效能優化（20%）：吞吐顯著提升（≥1.5×）
• 創新性（10%）：提出額外優化（如雙緩衝、動態 chunk）

Case #2: 用階段量測拆解「無瓶頸但很慢」的性能迷霧

Problem Statement（問題陳述）

業務場景：後端服務傳輸大型檔案時，監控顯示 CPU、網路、磁碟使用率皆低，然而用戶仍感覺「很慢」。缺乏進一步數據支持，團隊無從下手，導致無效調整（如盲目升級 VM 規格）增加成本。 技術挑戰：需要辨識時間都消耗在哪個階段（Read/Process/Write），並解釋為何整體時間大於各階段時間總結的「換手等待」。 影響範圍：優化方向不明、研發時間浪費、成本增加。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 無分段量測：只有總耗時，缺少階段耗時。
2. 指標解讀誤區：CPU/網路未滿載即認為無瓶頸。
3. 缺少可視化：無法看到 Read/Process/Write 的時間重疊與等待。

深層原因：

• 架構層面：無性能剖析（profiling）內建能力。
• 技術層面：未使用 Stopwatch/計數器記錄階段時間。
• 流程層面：未建立性能證據導向的診斷流程。

Solution Design（解決方案設計）

解決策略：在現有程式碼引入 Stopwatch 量測 Read/Process/Write 累積時間與總時間，計算理論重疊潛力，作為是否導入 async/await 的決策依據。

實施步驟：

1. 注入 Stopwatch
   • 實作細節：為三個階段與總流程分別起停錶
   • 所需資源：System.Diagnostics
   • 預估時間：0.5 小時
2. 增加報表輸出
   • 實作細節：以 Console 或日誌輸出階段與總時間
   • 所需資源：NLog/Serilog（可選）
   • 預估時間：0.5 小時
3. 分析與決策
   • 實作細節：若總時間≈各階段總和即代表無重疊；估算可重疊潛力
   • 所需資源：Excel/腳本
   • 預估時間：1 小時

關鍵程式碼/設定：

// 以 Stopwatch 量測各階段，用於找出「可重疊」潛力
static Stopwatch readT=new(), procT=new(), writeT=new(), allT=new();

static void Read(){ readT.Start(); Task.Delay(200).Wait(); readT.Stop(); }
static void Process(){ procT.Start(); Task.Delay(300).Wait(); procT.Stop(); }
static void Write(){ writeT.Start(); Task.Delay(500).Wait(); writeT.Stop(); }

static void Main(){
  allT.Start();
  for(int i=0;i<10;i++){ Read(); Process(); Write(); }
  allT.Stop();
  Console.WriteLine($"Total: {allT.ElapsedMilliseconds}ms, Read:{readT.ElapsedMilliseconds}ms, Proc:{procT.ElapsedMilliseconds}ms, Write:{writeT.ElapsedMilliseconds}ms");
}

實際案例：模擬 10 次迭代（200/300/500ms），階段時間分別約 2000/3000/5000 ms，總時間約 10,000 ms，顯示幾乎無重疊。 實作環境：.NET 4.5/C#5.0 實測數據：

• 改善前：總時間 10,000 ms
• 改善後（導入 async，見 Case #1）：約 5,500 ms
• 改善幅度：時間縮短約 44%，吞吐約 1.8×（理論重疊潛力被釋放）

Learning Points（學習要點） 核心知識點：

• 「總時間 > 任一階段時間」即存在重疊空間
• 指標解讀以時間為先，資源使用率為輔
• 量測即文檔：數據驅動優化決策

技能要求：

• 必備技能：Stopwatch、日誌
• 進階技能：分析與模型估算（理論上限）

延伸思考：

• 可擴展至更多階段（壓縮/加密/網傳）
• 限制：僅顯示「是否可重疊」，不自動優化
• 優化：結合可視化工具（火焰圖/時間軸）

Practice Exercise（練習題）

• 基礎：為現有 API 加入階段計時（30 分鐘）
• 進階：輸出 CSV 做趨勢圖（2 小時）
• 專案：建立性能儀表板（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：完整輸出四個時間
• 程式碼品質（30%）：無侵入性、易移除
• 效能優化（20%）：支持後續成功優化
• 創新性（10%）：自動化報表

Case #3: 最小改動策略：僅改寫 Write 為 async，維持 90% 原碼結構

Problem Statement（問題陳述）

業務場景：既有服務已上線，重構風險高；希望在「不大改架構、不大改流程」的前提下改善大型檔案串流效能。 技術挑戰：以最小改動量導入 async/await，同時保持輸出順序並避免大量緩衝。 影響範圍：降低改動風險與回歸測試範圍。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 有效重疊發生在 Write，因 Write 為 I/O 等待。
2. 改動越多風險越大，團隊抗拒重構。
3. 舊碼使用同步 API，無法直接併行。

深層原因：

• 架構層面：缺少分層隔離，難以在多點導入異步。
• 技術層面：未用 TAP，Write 被阻塞。
• 流程層面：回歸成本高。

Solution Design（解決方案設計）

解決策略：僅將 Write 改為 async Task，並在迴圈中以「上一輪 Write Task」實現一格前視。其餘 Read/Process 保持原狀，達到低風險高收益。

實施步驟：

1. 為 Write 增加 async 與 await
2. 於 DoWork 迴圈保存上一輪的 Task
3. 確保在新一輪開始前 await 前一輪（順序正確）
4. 測試與壓測

關鍵程式碼/設定：

public static async Task WriteAsync(){ writeT.Start(); await Task.Delay(500); writeT.Stop(); }

private static async Task DoWork(){
  Task prev=null;
  for(int i=0;i<10;i++){
    Read(); Process();
    if(prev!=null) await prev;
    prev=WriteAsync();
  }
  if(prev!=null) await prev;
}

實際案例：僅動到 Write 與迴圈處理，約 90% 程式碼與結構維持不變。 實作環境：.NET 4.5/C#5.0 實測數據：

• 改善前：10,000 ms
• 改善後：5,500~5,660 ms
• 改善幅度：時間縮短約 44%，吞吐約 1.8×

Learning Points（學習要點） 核心知識點：

• 「最小改動」也能達成大幅提升
• 順序性保障與重疊可以同時滿足
• 認清 I/O 等待是優化突破口

技能要求：

• 必備技能：async/await、任務生命週期
• 進階技能：在複雜碼庫中定位最小改動面

延伸思考：

• 何時需要雙緩衝以減少拷貝
• 如需多重寫入並行，如何控制背壓
• 錯誤處理與取消（CancellationToken）

Practice Exercise（練習題）

• 基礎：把同步 Write 改成 async（30 分鐘）
• 進階：引入取消與錯誤傳遞（2 小時）
• 專案：將第三方 SDK 寫入改為 async 管線（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：輸出正確有序
• 程式碼品質（30%）：改動小、清晰
• 效能優化（20%）：吞吐明顯提升
• 創新性（10%）：兼顧取消/重試

Case #4: 將「檔案複製 while 迴圈」重寫為可重疊的通用管線（Stream→Stream）

Problem Statement（問題陳述）

業務場景：大量檔案搬移/複製流程使用 while 迴圈讀滿 buffer 再寫出，無特別優化。大檔（數百 MB）時耗時長且資源利用不均。 技術挑戰：不額外引入繁複框架，實作通用的 Stream→Stream 非同步管線，實現一格前視與順序保障。 影響範圍：ETL、備份還原、媒體轉檔等多場景。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 傳統 while 迴圈串行讀寫。
2. 使用同步 Read/Write 阻塞。
3. 未控制寫出順序/背壓。

深層原因：

• 架構層面：無管線化思維。
• 技術層面：未使用 ReadAsync/WriteAsync。
• 流程層面：未建立可重用傳輸元件。

Solution Design（解決方案設計）

解決策略：使用雙緩衝與上一輪寫出任務的 await，將「上一塊寫出」與「下一塊讀取（與處理）」重疊。

實施步驟：

1. 設計雙緩衝與指標
2. 使用 Stream.ReadAsync / Stream.WriteAsync
3. 保留上一輪寫出任務，下一輪開始前 await
4. 單元測試與壓測

關鍵程式碼/設定：

async Task CopyPipelinedAsync(Stream src, Stream dst, int bufSize=64*1024, CancellationToken ct=default){
  var buf1=new byte[bufSize]; var buf2=new byte[bufSize];
  byte[] cur=buf1, prev=buf2;
  Task prevWrite=null; int read;
  while((read=await src.ReadAsync(cur,0,cur.Length,ct))>0){
    if(prevWrite!=null) await prevWrite; // 確保順序
    // 如需處理，對 prev/其長度做 Process() 再寫出
    var toWrite=prev; var len=read; // 若要處理，請保存 read 長度
    (cur,prev)=(prev,cur); // 交換緩衝，下一次讀入另一塊
    prevWrite = dst.WriteAsync(toWrite,0,len,ct).AsTask();
  }
  if(prevWrite!=null) await prevWrite;
}

實際案例：以 200/300/500ms 模擬，可將 10,000 ms 降至約 5,500 ms。 實作環境：.NET 4.5+/C#5.0 實測數據：

• 改善前：10,000 ms
• 改善後：5,500 ms
• 改善幅度：時間縮短 44%，吞吐約 1.8×

Learning Points（學習要點） 核心知識點：

• 雙緩衝與一格前視模式
• ReadAsync/WriteAsync 的正確用法
• 順序性與背壓控制

技能要求：

• 必備技能：非同步 I/O、緩衝管理
• 進階技能：零拷貝/Span 優化（延伸）

延伸思考：

• 可擴展為 N 段管線（加入轉碼、壓縮）
• 限制：Process 若極耗 CPU，需另行併行
• 優化：ArrayPool 降低 GC 壓力

Practice Exercise（練習題）

• 基礎：實作上述 CopyPipelinedAsync（30 分鐘）
• 進階：加入簡單 CPU Process，驗證順序與效能（2 小時）
• 專案：替換專案中的所有大檔 Copy（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：資料正確、順序無誤
• 程式碼品質（30%）：緩衝管理清楚
• 效能優化（20%）：吞吐顯著提升
• 創新性（10%）：池化/零拷貝

Case #5: Azure Blob → Web Response 的端到端非同步串流

Problem Statement（問題陳述）

業務場景：Web API 需從 Azure Blob 讀取大檔，做輕量處理後直接寫入 HTTP Response，期望縮短端到端延遲與提升吞吐。 技術挑戰：同時滿足即時性、順序性與資源利用率；避免阻塞 ASP.NET 要求執行緒。 影響範圍：影響最終用戶下載速率與服務併發能力。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 同步讀寫導致阻塞，併發能力下降。
2. Read/Process/Write 無重疊。
3. 客戶端網路（Write）成為主要變數，未針對此進行管線化。

深層原因：

• 架構層面：未將端到端串流視為管線。
• 技術層面：未使用 OpenReadAsync/WriteAsync。
• 流程層面：無壓測矩陣（不同 client 頻寬）。

Solution Design（解決方案設計）

解決策略：採用一格前視與雙緩衝，將 Blob 讀取與 Response 寫出錯位重疊，確保輸出順序，端到端全鏈路 async。

實施步驟：

1. 以 SDK 開啟 Blob 非同步讀取（OpenReadAsync）
2. 設定 Response 標頭與非同步輸出
3. 雙緩衝 + 上一輪寫出 Task await
4. 壓測不同客戶端頻寬

關鍵程式碼/設定：

// 以 Azure.Storage.Blobs 為例（亦可用舊版 SDK OpenRead）
public async Task StreamBlobAsync(HttpResponse resp, BlobClient blob, CancellationToken ct){
  await using var src = await blob.OpenReadAsync(cancellationToken: ct);
  resp.ContentType = "application/octet-stream";
  var buf1 = ArrayPool<byte>.Shared.Rent(64*1024);
  var buf2 = ArrayPool<byte>.Shared.Rent(64*1024);
  try{
    byte[] cur=buf1, prev=buf2;
    Task prevWrite=null; int bytesRead;
    while((bytesRead=await src.ReadAsync(cur,0,cur.Length,ct))>0){
      if(prevWrite!=null) await prevWrite; // 確保順序
      var toWrite = prev; var len = bytesRead;
      (cur,prev)=(prev,cur);
      prevWrite = resp.Body.WriteAsync(toWrite,0,len,ct).AsTask();
    }
    if(prevWrite!=null) await prevWrite;
    await resp.Body.FlushAsync(ct);
  } finally{
    ArrayPool<byte>.Shared.Return(buf1,true);
    ArrayPool<byte>.Shared.Return(buf2,true);
  }
}

實際案例：100MB 串流，在客戶端頻寬為 80 Mbps 時最佳，總時間可由 ~10s 降至 ~5.5s。 實作環境：.NET 4.5+/ASP.NET、Azure Storage Blob 實測數據（取自文中測試模型）：

• 原花費時間（80M）：10,000 ms
• ASYNC 花費時間（80M）：5,500 ms
• 改善幅度：時間縮短 45%，吞吐約 1.82×

Learning Points（學習要點） 核心知識點：

• 端到端串流的 async/await 實作
• 雙緩衝與順序保障
• 依客戶端頻寬而變化的效能曲線

技能要求：

• 必備技能：Azure Blob SDK、ASP.NET 非同步回應
• 進階技能：頻寬模擬與壓測

延伸思考：

• 傳輸中壓縮/轉碼如何插入管線
• 大量並發時的背壓策略
• TLS/壓縮對 CPU 的影響

Practice Exercise（練習題）

• 基礎：打通 Blob→Response 的非同步串流（30 分鐘）
• 進階：加入輕量處理（例如簡單轉碼）（2 小時）
• 專案：建立可配置緩衝大小與壓測報告（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：正確串流至前端
• 程式碼品質（30%）：非同步正確、資源回收
• 效能優化（20%）：達成明顯縮時
• 創新性（10%）：壓測與報表自動化

Case #6: 頻寬敏感度分析：不同客戶端頻寬下的效益曲線

Problem Statement（問題陳述）

業務場景：客戶端頻寬差異巨大（2–200 Mbps），導入 async 後的效益不一致，需量化各頻寬下的預期縮時與提升倍數，以支持商業決策。 技術挑戰：建立簡易模型與數據表，指導是否導入 async。 影響範圍：影響研發優先順序與資源配置。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. Write 時間取決於客戶端頻寬。
2. Read+Process 與 Write 時間差距影響重疊效果。
3. 無數據支持決策。

深層原因：

• 架構層面：無 A/B 與敏感度分析流程。
• 技術層面：缺模型估算。
• 流程層面：缺效益門檻（如 <10% 視為無感）。

Solution Design（解決方案設計）

解決策略：使用文中測試數據表建模，計算各頻寬的原耗時、ASYNC 耗時與提升百分比，挑選最具效益檔位優先導入。

實施步驟：

1. 準備頻寬與耗時表
2. 繪製折線與改善百分比
3. 設定門檻（例如 <10% 不導入）

關鍵程式碼/設定：

// 可將文中表格寫入資料結構，輸出改善百分比
var data = new (int bwMbps, int origMs, int asyncMs)[]{
 (200,7000,5500),(100,9000,5500),(80,10000,5500),(50,13000,8500),
 (20,25000,20500),(10,45000,40500),(5,85000,80500),(2,205000,200500)
};
foreach(var d in data){
  double speedup = (double)d.origMs / d.asyncMs; // 倍數
  double reduction = 100.0 * (d.origMs - d.asyncMs) / d.origMs; // 百分比縮時
  Console.WriteLine($"{d.bwMbps}Mbps: {d.origMs}->{d.asyncMs} ms, x{speedup:F2}, -{reduction:F1}%");
}

實測數據（來自文章模型）：

• 80 Mbps：10,000→5,500 ms（x1.82，-45%）
• 50 Mbps：13,000→8,500 ms（x1.53，-34.6%）
• 2 Mbps：205,000→200,500 ms（x1.02，-2.2%）

Learning Points（學習要點） 核心知識點：

• 最佳效益發生於 Write ≈ Read+Process
• 頻寬越低，Write 越長，重疊效果越小
• 設置「無感」閾值（<10%）避免過度工程

技能要求：

• 必備技能：基本資料分析
• 進階技能：場景建模與決策制定

延伸思考：

• 可依地區/ISP 建立頻寬分佈，估算加權效益
• 限制：模型簡化，需以真實壓測校準
• 優化：動態調整 chunk 大小/策略以貼近最佳點

Practice Exercise（練習題）

• 基礎：輸出折線圖（30 分鐘）
• 進階：以真實壓測數據替換模型（2 小時）
• 專案：建立效益儀表板（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：完整輸出各項指標
• 程式碼品質（30%）：清晰易維護
• 效能優化（20%）：能正確指導決策
• 創新性（10%）：視覺化呈現

Case #7: 何時用 Async/Await、何時用 Thread：決策準則與驗證

Problem Statement（問題陳述）

業務場景：需要決定是以 async/await 還是多執行緒來優化。錯誤選擇導致複雜度提升卻無效益。 技術挑戰：建立可重複的決策準則與驗證方法。 影響範圍：架構複雜度、維護成本、效能成效。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 將 I/O 等待誤當為 CPU 需擴展。
2. 過度使用 Thread 造成結構破碎。
3. 無驗證步驟，靠直覺選型。

深層原因：

• 架構層面：缺少「I/O-bound vs CPU-bound」分類流程。
• 技術層面：不了解 TAP 與 Thread 適用情境。
• 流程層面：無前置實驗以驗證假設。

Solution Design（解決方案設計）

解決策略：以階段量測辨識是否為 I/O-bound；I/O-bound 優先 async/await；CPU-bound 再考慮平行化（多執行緒/平行 LINQ）。以縮時與吞吐提升作為驗證指標。

實施步驟：

1. 階段量測（Case #2）
2. 模擬與估算（Case #6）
3. 原型驗證（最小改動 async/await）
4. 若 CPU-bound 再評估 Thread/PLINQ

關鍵程式碼/設定：同 Case #1/#2 的量測與一格前視實作。

實測數據：見 80 Mbps 場景，async 可達 ~1.82×，屬 I/O-bound 典型案例。 實作環境：.NET 4.5/C#5.0 實測結論：此類「片段任務非同步、時序精準」以 async/await 可讀性與效益更佳。

Learning Points（學習要點） 核心知識點：

• I/O-bound vs CPU-bound 的選型準則
• async/await 的結構優勢（90% 原碼保留）
• 指標導向的架構決策

技能要求：

• 必備技能：診斷、TAP、PLINQ 基礎
• 進階技能：POC 驗證與風險控管

延伸思考：

• 混合型（I/O + CPU）如何分而治之
• 大規模並行的 Thread 決策點
• 程式碼可維護性評估

Practice Exercise（練習題）

• 基礎：為既有問題分類（30 分鐘）
• 進階：針對兩種方案各寫 POC 並比較（2 小時）
• 專案：撰寫選型準則與模板（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：產出決策結論
• 程式碼品質（30%）：POC 清晰
• 效能優化（20%）：指標佐證
• 創新性（10%）：準則可重用

Case #8: CPU-bound 處理與 I/O 非同步的分工：只對 I/O 做 async

Problem Statement（問題陳述）

業務場景：Process 階段為 CPU-bound（如解碼/編碼），Read/Write 為 I/O-bound。如何避免「為了 CPU 工作誤用 async」造成複雜度與錯誤期待。 技術挑戰：僅讓 I/O 非同步化，CPU 工作維持同步，藉由重疊提升整體效率。 影響範圍：處理階段的正確分工與效益評估。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 誤把 CPU 工作 async 化（無效且徒增複雜）。
2. 不理解 I/O 等待才是重疊空間。
3. 混淆 await 帶來的語意與性能。

深層原因：

• 架構層面：無清楚的階段分類。
• 技術層面：忽略 CPU-bound 的平行策略另議。
• 流程層面：無效能假設驗證。

Solution Design（解決方案設計）

解決策略：保留 Process 為同步方法；僅將 Write（與可能的 ReadAsync）非同步並做一格前視；必要時另以 Thread/PLINQ 處理多核平行。

實施步驟：

1. 將 Read→ReadAsync、Write→WriteAsync
2. 保留 Process 同步
3. 一格前視疊加 I/O 與 CPU
4. 視需要評估多核平行 Process（另案）

關鍵程式碼/設定：

void Process(){ /* CPU-bound，保持同步 */ /* e.g., 編碼 */ }
async Task WriteAsync(){ await Task.Delay(500); }

async Task Loop(){
  Task prev=null;
  for(int i=0;i<10;i++){
    // Read 可為 ReadAsync，簡化以同步代表
    Read(); 
    Process(); // CPU 工作
    if(prev!=null) await prev;
    prev = WriteAsync(); // I/O 非同步重疊 CPU
  }
  if(prev!=null) await prev;
}

實測數據：同 200/300/500ms 模型，僅 I/O 非同步即可達 ~1.8× 提升（最佳頻寬區間）。 實作環境：.NET 4.5/C#5.0

Learning Points（學習要點） 核心知識點：

• CPU-bound 不因 async 本身加速
• I/O 等待才是重疊空間
• CPU 平行需另採平行化工具

技能要求：

• 必備技能：I/O vs CPU 邏輯分離
• 進階技能：PLINQ/ThreadPool 管理

延伸思考：

• 當 Process 極重時，應分拆為獨立平行階段
• 小心同步化帶來的鎖競爭
• 觀察 CPU 飽和度與熱點

Practice Exercise（練習題）

• 基礎：僅將 I/O async 化（30 分鐘）
• 進階：加入 CPU 平行策略（2 小時）
• 專案：建立混合型管線（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：輸出正確
• 程式碼品質（30%）：分工清晰
• 效能優化（20%）：I/O 與 CPU 能重疊
• 創新性（10%）：混合策略設計

Case #9: 有序輸出與背壓控制：只保留「一筆未完成的寫入」

Problem Statement（問題陳述）

業務場景：串流輸出需嚴格維持順序；若同時啟動多個 Write 可能造成重排或記憶體占用飆升。 技術挑戰：在重疊 I/O 與 CPU 的同時，控制未完成 Write 的數量與輸出順序。 影響範圍：資料正確性、記憶體占用、穩定性。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 多個並行 Write 可能造成 out-of-order。
2. 併發 Write 增加記憶體壓力。
3. 無背壓機制，生產 > 消費。

深層原因：

• 架構層面：管線缺少速率匹配。
• 技術層面：await 不當使用導致順序問題。
• 流程層面：未定義併發上限與背壓。

Solution Design（解決方案設計）

解決策略：限制同時僅有「上一筆 Write 未完成」，下一輪開始前 await 前一筆；以此保證順序與背壓，避免無界度成長。

實施步驟：

1. 增加 prevWrite Task 變數
2. 在下一輪開始前 await prevWrite
3. 僅啟動一個未完成 Write

關鍵程式碼/設定：

Task prevWrite=null;
while(hasMore){
  Read(); Process();
  if(prevWrite!=null) await prevWrite; // 背壓+順序
  prevWrite = WriteAsync();
}
if(prevWrite!=null) await prevWrite;

實測數據：在 80 Mbps 下，達到與 Case #1 相同 ~1.8× 提升；同時避免多筆未完成寫入導致的記憶體膨脹。 實作環境：.NET 4.5/C#5.0

Learning Points（學習要點） 核心知識點：

• 背壓（Backpressure）基本策略
• 有序性保障與重疊的平衡
• 單一未完成 Write 的工程實作

技能要求：

• 必備技能：await 正確時機
• 進階技能：併發控制與資源限速

延伸思考：

• 若要多筆並行寫入，如何更改協定保序
• 可否以序號/重排序佇列保障順序
• 以計量閥（Token）實現更彈性的背壓

Practice Exercise（練習題）

• 基礎：實作單一未完成 Write（30 分鐘）
• 進階：加入序號與重排序（2 小時）
• 專案：可配置併發與背壓策略（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：順序正確
• 程式碼品質（30%）：邏輯清晰
• 效能優化（20%）：吞吐提升且穩定
• 創新性（10%）：背壓策略可配置

Case #10: 用時間軸推估最佳點：Read+Process ≈ Write 的設計準則

Problem Statement（問題陳述）

業務場景：如何在設計階段估算最佳效益點，避免盲目調整緩衝大小或處理強度。 技術挑戰：建立簡單時間軸模型，推估最佳區間。 影響範圍：設計決策與調參效率。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 未有準則指導「讀/處理/寫」的時間搭配。
2. 調參盲目無效率。
3. 不知道何時效益下降。

深層原因：

• 架構層面：缺時間軸導向設計。
• 技術層面：忽略重疊的數學模型。
• 流程層面：無預估→驗證迴圈。

Solution Design（解決方案設計）

解決策略：以時間軸分析，當 Read+Process ≈ Write 時，重疊面積最大，效益最佳；高於/低於皆打折。以此作為調參的目標方向（例如調整 chunk 大小/處理強度）。

實施步驟：

1. 量測三階段時間
2. 設定調參方向（讓兩側靠近）
3. 驗證不同參數下耗時與吞吐

關鍵程式碼/設定：參考 Case #2 的量測與 Case #6 的敏感度分析。

實測數據：文章指出改善幅度最佳發生在 80 Mbps，正好 Read+Process ≈ Write。 實作環境：.NET 4.5/C#5.0

Learning Points（學習要點） 核心知識點：

• 重疊面積與兩側時間相等的關係
• 最佳點識別與調參方向
• 以數據而非直覺驅動

技能要求：

• 必備技能：量測/圖表
• 進階技能：參數掃描與擬合

延伸思考：

• 何時應改變架構而非微調參數
• 自動化參數搜尋
• 對不同檔案大小的適用性

Practice Exercise（練習題）

• 基礎：畫出時間軸（30 分鐘）
• 進階：嘗試不同 chunk 大小（2 小時）
• 專案：實作自動化調參腳本（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：能找出最佳點
• 程式碼品質（30%）：數據處理清楚
• 效能優化（20%）：有實際提升
• 創新性（10%）：自動化程度

Case #11: 建立可重複的延遲模擬器（Task.Delay Harness）驗證假設

Problem Statement（問題陳述）

業務場景：在未接觸真實雲資源前，需快速驗證 async 管線的理論效益。 技術挑戰：用 Task.Delay 模擬 Read/Process/Write 時間，復現效能曲線。 影響範圍：POC 效率、風險控制。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 真實資源昂貴、取得不便。
2. 設計需快速迭代。
3. 欠缺可重複的基準。

深層原因：

• 架構層面：缺乏 POC 階段
• 技術層面：未建立模擬環境
• 流程層面：未把關鍵假設前置驗證

Solution Design（解決方案設計）

解決策略：以 Task.Delay(200/300/500) 模擬三階段，建立同步版與 async 管線版兩種基準，對比總耗時。

實施步驟：

1. 撰寫同步基準
2. 撰寫 async 管線版（Case #1）
3. 對比並輸出數據

關鍵程式碼/設定：同文章示例程式。

實測數據：

• 同步：~10,000 ms
• 非同步：~5,500–5,660 ms
• 提升：~1.8×

Learning Points（學習要點） 核心知識點：

• 快速建模驗證
• 控制變數（固定 10 次）
• POC → 上線路徑

技能要求：

• 必備技能：C#/Task.Delay
• 進階技能：基準測試方法論

延伸思考：

• 將模擬器參數化（自助服務）
• 以此教學新成員 async 模式
• 導入自動化測試

Practice Exercise（練習題）

• 基礎：寫出兩版並對比（30 分鐘）
• 進階：產生報表（2 小時）
• 專案：建立 CI 中的性能守門（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：可重現結果
• 程式碼品質（30%）：結構清楚
• 效能優化（20%）：證明假設成立
• 創新性（10%）：參數化程度

Case #12: 用簡單公式預估加速比與縮時率

Problem Statement（問題陳述）

業務場景：產品/專案管理者希望在投資前看到預估效益。 技術挑戰：以階段時間估算加速比與縮時率，並與實測驗證。 影響範圍：投資決策、路線規劃。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 無預估模型。
2. 難以向非技術利害關係人說明。
3. 缺乏統一口徑。

深層原因：

• 架構層面：無性能預估工具
• 技術層面：缺少簡單公式
• 流程層面：無預估→驗證迴圈

Solution Design（解決方案設計）

解決策略：以 Tread、Tproc、Twrite 代表三階段時間；同步總時間 Tsync = Σ Ti；一格前視 async 總時間近似 Tasync ≈ max(Tread+Tproc, Twrite) × 次數 + 首尾邊界損耗。加速比 ≈ Tsync / Tasync，縮時率 = 1 - (Tasync / Tsync)。

實施步驟：

1. 量測三階段時間
2. 套用公式估算
3. 用小規模壓測驗證

關鍵程式碼/設定：可用簡單腳本/Excel 計算。

實測數據：以 200/300/500ms、10 次為例：

• Tsync = 10000 ms；Tasync ≈ 5500–5660 ms
• 加速比 ≈ 1.8×；縮時率 ≈ 44–45%

Learning Points（學習要點） 核心知識點：

• 預估與實測的對齊
• 邊界效應（首/尾不可重疊）
• 用簡單模型說服決策者

技能要求：

• 必備技能：代數推導
• 進階技能：用數據講故事

延伸思考：

• 更複雜的多段管線如何估算
• 誤差來源與校準
• 與成本模型結合

Practice Exercise（練習題）

• 基礎：帶入數據計算（30 分鐘）
• 進階：寫個估算器 CLI/腳本（2 小時）
• 專案：估算多場景效益（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：能預估主要指標
• 程式碼品質（30%）：簡潔準確
• 效能優化（20%）：與實測接近
• 創新性（10%）：可視化輸出

Case #13: 觀測先行：用「資源未滿載 + 總時間過長」判定 async 機會點

Problem Statement（問題陳述）

業務場景：團隊需要一套快速判定「是否適合 async 優化」的方法，以便篩選專案。 技術挑戰：建立判定信號與驗證清單。 影響範圍：節省研發時間，聚焦高價值專案。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 主要資源（CPU/網路/磁碟）皆非飽和。
2. 總時間卻長，與理想值落差大。
3. 無判定清單。

深層原因：

• 架構層面：無性能 triage
• 技術層面：缺少觀測與門檻
• 流程層面：優先順序不明

Solution Design（解決方案設計）

解決策略：以「資源未滿載 + 階段時間可重疊」為信號，先做 Stopwatch 階段量測，若 Tsync 接近 ΣTi，則嘗試 async 一格前視。設門檻（預估提升 <10% 不進行）。

實施步驟：

1. 收集資源監控（CPU、網、盤）
2. 階段量測（Case #2）
3. 估算效益（Case #12）
4. 決策與排程

關鍵程式碼/設定：同 Case #2。

實測數據：原文案例中資源皆非瓶頸，導入 async 後達 ~1.8×。 實作環境：.NET 4.5/C#5.0

Learning Points（學習要點） 核心知識點：

• 快速判定 async 機會點
• 量測→估算→執行→驗證流程
• 設置「無感」閾值

技能要求：

• 必備技能：監控工具使用
• 進階技能：效益評估

延伸思考：

• 自動化檢查清單
• 與容量規劃結合
• 風險控管（漸進式上線）

Practice Exercise（練習題）

• 基礎：撰寫判定清單（30 分鐘）
• 進階：建立腳本讀取監控與輸出建議（2 小時）
• 專案：導入到團隊流程（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：清單可用
• 程式碼品質（30%）：工具可靠
• 效能優化（20%）：能篩選高 ROI 項目
• 創新性（10%）：自動化程度

Case #14: 用 async/await 取代多執行緒，維持高可讀性與低侵入

Problem Statement（問題陳述）

業務場景：過往以多執行緒與佇列實作管線，維護困難、除錯成本高；想在保持性能的同時提升可讀性。 技術挑戰：用 async/await 達到相同的重疊效果，且保留原本 90% 程式結構。 影響範圍：可維護性、缺陷率、上手速度。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. Thread/Queue 版結構破碎、回呼地獄。
2. 同步/非同步混雜造成錯誤。
3. 缺統一的錯誤傳遞與取消。

深層原因：

• 架構層面：未採 TAP 模式。
• 技術層面：回呼式難閱讀。
• 流程層面：維護負擔高。

Solution Design（解決方案設計）

解決策略：將關鍵 I/O 點 async 化，以 await 建立直覺控制流程（順序點），替代顯式執行緒管理；重疊與順序一目了然。

實施步驟：

1. 找出 I/O 點（Read/Write）改為 async
2. 建立 await 順序點（前輪 Write 完成）
3. 保持 Process 同步
4. 加入取消與例外流

關鍵程式碼/設定：同 Case #1/#3。

實測數據：性能接近多執行緒實作，同時可讀性顯著提升（保留 90% 結構）。 實作環境：.NET 4.5/C#5.0

Learning Points（學習要點） 核心知識點：

• TAP 的可讀性與可維護性
• 非同步錯誤/取消的標準化
• 最小侵入重構

技能要求：

• 必備技能：async/await、例外/取消
• 進階技能：重構策略

延伸思考：

• 與 Dataflow/Channel 等模型比較
• 日後擴展至多段管線
• 可觀測性與測試性

Practice Exercise（練習題）

• 基礎：以 async/await 重寫舊 Thread 版（30 分鐘）
• 進階：加入取消與錯誤泡泡（2 小時）
• 專案：完成一支端到端替換（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：行為一致
• 程式碼品質（30%）：簡潔、可讀
• 效能優化（20%）：效能不退步
• 創新性（10%）：最佳實務運用

Case #15: 從 3.5 Mbps 到逼近原始來源：實務場景效益總結與邊界

Problem Statement（問題陳述）

業務場景：Web 中繼節點將 Blob 串流給前端，效能僅約 3.5 Mbps，相對直接從 Blob 取得約 7.3 Mbps 差距明顯。需判定導入 async 後可達效益與邊界。 技術挑戰：界定「最佳可達」與「邊界條件」：當 Write 遠大於或小於 Read+Process 時，效益有限。 影響範圍：使用者體驗與雲成本。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 以順序 while 迴圈串行處理。
2. I/O 等待與 CPU 工作不重疊。
3. 客戶端頻寬變因大。

深層原因：

• 架構層面：中繼節點未管線化。
• 技術層面：未用 async/await。
• 流程層面：無多頻寬壓測矩陣。

Solution Design（解決方案設計）

解決策略：導入一格前視 async 管線，使 Read/Process 與 Write 重疊；依 Case #6 之頻寬敏感度，評估不同客戶端環境的期待效益。

實施步驟：

1. 導入 async 管線（Case #1/#5）
2. 以頻寬矩陣進行壓測
3. 設效率下限（<10% 無感）

關鍵程式碼/設定：同 Case #5。

實際案例：原文指出 3.5 Mbps（中繼） vs 7.3 Mbps（直接）；模型顯示在 80 Mbps（Write ≈ Read+Process）時，總時間可由 10s 降至 5.5s（x1.82）。 實作環境：.NET 4.5/C#5.0、Azure Blob 實測數據（模型+實測結論）：

• 改善前：3.5 Mbps（參考實務）、10,000 ms（模型）
• 改善後：視頻寬而定；在 80 Mbps 代表性情境可達 x1.82；在 2 Mbps 僅 ~x1.02
• 改善幅度：依頻寬而變，最佳點在 Write ≈ Read+Process

Learning Points（學習要點） 核心知識點：

• 實務效益的上下限與影響因子
• 頻寬敏感度的決策價值
• 用數據避免過度工程

技能要求：

• 必備技能：壓測與指標分析
• 進階技能：效益溝通與產品決策

延伸思考：

• 是否允許客戶端分流（直連 Blob）
• CDN/快取策略整合
• 服務分級（高頻寬客戶優先優化）

Practice Exercise（練習題）

• 基礎：針對三種頻寬做壓測（30 分鐘）
• 進階：產出決策報告（2 小時）
• 專案：端到端優化與上線（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：壓測完整
• 程式碼品質（30%）：非同步正確
• 效能優化（20%）：達標
• 創新性（10%）：決策含金量

—————————— 案例分類

1. 按難度分類
   • 入門級（適合初學者）：Case 2, 6, 10, 11, 12, 13
   • 中級（需要一定基礎）：Case 1, 3, 4, 5, 7, 8, 9, 14, 15
   • 高級（需要深厚經驗）：（本批案例以中級為主，若延伸至多段管線/多併發排序可視為高級）
2. 按技術領域分類
   • 架構設計類：Case 7, 10, 13, 14, 15
   • 效能優化類：Case 1, 3, 4, 5, 6, 8, 9, 12
   • 整合開發類：Case 4, 5
   • 除錯診斷類：Case 2, 11, 13
   • 安全防護類：無（本文聚焦性能，不涉及安全設計）
3. 按學習目標分類
   • 概念理解型：Case 6, 10, 12, 13
   • 技能練習型：Case 2, 3, 4, 5, 11
   • 問題解決型：Case 1, 7, 8, 9, 15
   • 創新應用型：Case 14（以 async/await 取代多執行緒）

—————————— 案例關聯圖（學習路徑建議）

• 建議先學：
  • Case 11（建立可重複的延遲模擬器）：快速理解問題結構與預期效益
  • Case 2（階段量測）：養成用數據說話的習慣

• 依賴關係與進階順序： 1) Case 11 → Case 2 → Case 12 → Case 6 → Case 13（模型、量測與判定） 2) Case 3 → Case 1（最小改動到完整一格前視）→ Case 9（背壓與順序） 3) Case 4（通用 Stream 管線）→ Case 5（Azure Blob→Response 實戰） 4) Case 8（CPU/I/O 分工）→ Case 7（Async vs Thread 選型）→ Case 14（可維護性重構） 5) 最後以 Case 10（最佳點準則）與 Case 15（實務效益總結）收束，形成「設計→實作→量測→決策」閉環

• 完整學習路徑建議：
  • 入門階段：Case 11 → Case 2 → Case 12 → Case 6
  • 實作階段：Case 3 → Case 1 → Case 9 → Case 4 → Case 5
  • 深化階段：Case 8 → Case 7 → Case 14 → Case 10
  • 收斂與決策：Case 13 → Case 15

此路徑從模型與量測出發，逐步過渡到最小改動實作與端到端整合，最後以選型、最佳化準則與實務效益進行收斂，能夠支持實戰教學、專案練習與能力評估的全流程。