Imgproxy vs Akamai CDN：圖片下載效能統計實測

前言

打造了一顆社群 App，內有一堆圖片在 load 的時候會黑黑的，過一陣子才 load 得出來。

目標

解決這個會讓用戶體驗不佳的問題，很快滑過去也不能看到黑黑的!

方法

網上 Survey (ChatGPT) 了一下，決定試試壓縮圖片，看能不能讓下載速度更快。壓縮的方式選用 Imgproxy 架在 AWS Loadbalancer 層級，人如其名，就是把它當成 proxy 使用。

Source Origin 為 S3，前面也加了一層 CDN。

因此拿圖的流程會長這樣：

接著就是看這樣的設計流程可不可以讓我們拿圖變快囉！

在開始之前，需要先知道從 S3 拉圖跟透過 imgproxy 從 S3 拉圖的速度差，才有比較的基準值。畢竟如果 imgproxy 本身就存在下載速度限制的話，再怎麼壓縮，拉圖就是會慢。

實驗設計

假設

Imgproxy 可以幫我加速圖片下載速度!

方法

比較各種情境的下載速度是否有差異：

• S3 vs Imgproxy → S3
• Akamai CDN → S3 vs Imgproxy → S3
• Akamai CDN → S3 vs CloudFront CDN → Imgproxy → S3
• 第一次緩存建立 CloudFront CDN → Imgproxy → S3 與第二三次緩存建立後 CloudFront CDN → Imgproxy → S3，下載速度差
• Akamai CDN → S3 vs 緩存建立後的 CloudFront CDN → Imgproxy → S3

測試環境

星巴克 Wi-Fi、AWS S3、AWS Loadbalancer (Imgproxy)、AWS CloudFront、Akamai CDN。

• 後面的 S3 前面的 CDN 都是 Akamai
• Imgproxy 前面的 CDN 都是 CloudFront

之後再來做一個 CloudFront → S3 vs CloudFront → Imgproxy → S3。

測試一:S3 vs Imgproxy → S3

目的

比較 S3 與 Imgproxy → S3 下載速度是否有差異。

假設

在 S3 前面放 Imgproxy 不影響下載速度。

方法

1. 控制組:S3
2. 對照組:Imgproxy → S3
3. 同一個檔案在控制組與對照組同時各下載三次，算平均值

數據分析

從 Imgproxy 進行下載，似乎存在速度限制 2 MB/s。從 S3 有較高的下載速度，但有條件:檔案在小於 2 MB 時可以有 Max 10.0 MB/s 的下載速度，但檔案大於 2.5 MB 時，存在檔案下載限制，約在 4 MB/s 以下。速度差也多落在 > 0 的地方，代表 S3 有較高下載速度。

結論: 目測兩者下載速度有差異，S3 快於 Imgproxy，但依據檔案大小，S3 也存在下載速度限制。

其他: 檔案大小多在 2.5 MB 以下。

Speed Difference 的計算方式：

'speed_difference_percent': ((mean([r['speed_mbps'] for r in original_results]) -
                              mean([r['speed_mbps'] for r in imgproxy_results])) /
                              mean([r['speed_mbps'] for r in original_results]) * 100)

也就是 (S3 平均下載速度 - Imgp 平均下載速度) / S3 下載速度。

所以如果是正的 (> 0)，代表 S3 比較快。而數據看起來都在 > 0 那一邊。

測試二:Akamai → S3 vs Imgproxy → S3

目的

比較 Akamai → S3 與 Imgproxy → S3 下載速度是否有差異。

假設

Akamai 與 Imgproxy 都存在下載速度限制瓶頸。

方法

1. 控制組:Akamai → S3
2. 對照組:Imgproxy → S3
3. 同一個檔案在控制組與對照組同時各下載三次，算平均值

數據分析

單純使用 Imgproxy 進行下載，存在速度限制 2 MB/s，Max 2.65 MB/s;使用 Akamai → S3 有較高的下載速度，Max 可以到 10.08 MB/s。

Speed Difference 基本上都 > 0。

結論: 加上 Akamai CDN 可以大幅增加下載速度。

那我們也來把 Imgproxy 前面加上 CloudFront CDN 看效果如何。

測試三:Akamai → S3 vs CloudFront → Imgproxy → S3

目的

驗證使用 CloudFront → Imgproxy 可有效提升下載速度。

假設

加上 CDN 可以大幅提升 Imgproxy 下載速度。

方法

1. 控制組:Akamai → S3
2. 對照組:CloudFront → Imgproxy → S3
3. 同一個檔案在控制組與對照組同時各下載三次，算平均值

數據分析

就平均值而言，看起來有一個 Max 8 MB/s 的速度限制。

Speed Difference 明顯往 < 0 偏移。

結論: 顯著提升，從 2 MB/s 到 8 MB/s。

測試四:CDN 緩存暖機效應(Wilcoxon 檢定)

目的

確認 CDN 緩存完全建立時性能最佳，比較 CloudFront → Imgproxy 第 1、2、3 次下載速度差異。

方法

1. 控制組:CloudFront → Imgproxy 第一次下載速度
2. 對照組:
   • CloudFront → Imgproxy → 第二次下載速度
   • CloudFront → Imgproxy → 第三次下載速度
3. 同一個檔案下載三次，用 Wilcoxon 檢定是否存在顯著差異
4. 假設檢定
   • 虛無假說 (H0): 不同下載次數之間無顯著差異。
   • 對立假說 (H1): 不同下載次數之間存在顯著差異。
5. 使用的檢定方法:由於數據不符合常態分佈，採用 Wilcoxon 符號等級檢定(Wilcoxon Signed-Rank Test)。

檢定結果

a. Speed1 vs Speed2

• CDN_Imgproxy:
  • W = 159.0，p = 6.52e-82(p < 0.05，顯著差異)
  • 解釋: 第二次下載速度顯著高於第一次。

b. Speed1 vs Speed3

• CDN_Imgproxy:
  • W = 38.0，p = 3.09e-83(p < 0.05，顯著差異)
  • 解釋: 第三次下載速度顯著高於第一次。

結論

• 第一次下載 (imgp_download_speed1):

  • 中位數約在 0.5–1.0 MB/s
  • 表現類似於無 CDN 的 Imgproxy
  • 原因是 CDN 尚未建立緩存

• 第二次下載 (imgp_download_speed2):

  • 中位數提升到約 4.0–4.5 MB/s
  • 速度分布明顯向上偏移
  • 顯示 CDN 緩存開始發揮作用

• 第三次下載 (imgp_download_speed3):

  • 中位數達到約 7.0–7.5 MB/s
  • 速度分布更加集中在較高區間
  • CDN 緩存完全建立，性能最佳

• CDN 的效果是漸進式的:

  • 首次訪問時受限於需建立緩存
  • 後續訪問性能顯著提升
  • 多次訪問後達到最佳性能

延伸分析

a. 原本 Imgproxy (without CDN) 是否也存在差異

其實三次 Imgproxy (without CDN) 下載速度原本就有差異!但第二跟第三次差不多，可能 Imgproxy 本身也有 cache?(待 Survey)

b. 緩存未建立 vs 已建立的影響

假設

Imgproxy 加上 CDN 可以讓下載速度增加，但是第一次建立時一樣有其限制。

方法

1. 控制組:CDN → S3
2. 對照組:CDN → Imgproxy → S3
3. 同一個檔案在控制組下載三次，算平均值，對照組僅下載第一次

數據分析

明顯 Imgproxy 第一次的結果又回到 2 MB/s。

如果藍點點在紅線上表示兩者下載速度一致。

結論: CDN Imgproxy 第一次下載流量會被 Imgproxy 速度限制。

因此看拿掉第一次下載數據，整體下載速度是否可以提升。

c. 緩存建立後再比較

假設

不考慮第一次緩存未建立情況，CDN 可以讓下載速度增加。

方法

1. 控制組:CDN → S3
2. 對照組:CDN → Imgproxy → S3
3. 同一個檔案在控制組下載三次，算平均值，在緩存建立下，平均對照組第二與第三次的下載速度

結論: 在緩存建立下，Imgproxy 的下載速度表現明顯提升，甚至稍微高於 S3。CDN 緩存機制影響下載速度。

統計驗證

1. 使用 Wilcoxon 檢定證實了性能提升的統計顯著性
2. 三次下載速度的差異具有統計學意義
3. 驗證了 CDN 緩存確實能改善下載性能

總結

1. Imgproxy (without CDN):

   • 單純使用 Imgproxy 的下載速度受限，第一次下載比第二三次慢，可能本身就有緩存機制。

2. CDN_Imgproxy:

   • 第一次下載速度與 Imgproxy (without CDN) 相近，因為 CDN 未快取。
   • 從第二次下載開始，由於啟用快取，CDN_Imgproxy 的下載速度顯著提高，並遠高於 Imgproxy。

3. CDN_S3:

   • 提供穩定且高速的下載速度，是最佳選擇。但我們要壓縮，所以接著應該要看壓縮的報告(見下一篇)。

後續

但其實 Akamai 也有壓縮轉檔的功能，因此之後想再做一篇 CloudFront → S3 vs CloudFront → Imgproxy → S3 的比較。