《 Imgproxy 使用分析一：圖片下載速度優化分析：Akamai CDN vs Imgproxy 效能比較》

前言

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

目標

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

方法

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

因此拿圖的流程會長這樣
圖1. cdn imgproxy s3 plantUML


接著就是看這樣的設計流程可不可以讓我們拿圖變快囉！
在開始之前，需要先知道

從 S3 拉圖跟透過 imgproxy 從 S3 拉圖的速度差

才有比較的基準值，畢竟如果 imgproxy 本身就存在下載速度限制的話，再怎麼壓縮，拉圖就是會慢啊！

實驗設計

假設

Imgroxy 可以幫我加速圖片下載速度！

方法

比較各種情境的下載速度是否有差異：
  • 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

測試環境

星巴克 wifi, AWS S3, AWS Loadbalancer (Imgproxy), AWS CloudFront, Akamai CDN
後面的 S3 前面的 CDN 都是 Akamai
Imgproxy 前面的 CDN 都是 CloudFront
之後再來做一個 CloudFront → S3 vs CloudFront → Imgproxy → S3

測試一

目的

S3 與 imgproxy → S3 下載速度是否有差異

假設

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

方法

  1. 控制組：S3

  2. 對照組：imgproxy → S3

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

數據分析

從 Imgproxy 進行下載，似乎存在速度限制 2MB (圖2.)
從 S3 有較高的下載速度，但有條件，檔案在小於 2MB 時可以有 Max 10.0 MB/s 的下載速度，但檔案大於 2.5MB 時，存在檔案下載限制，約在 4 MB/s 以下。
速度差(圖3. )也多落在 > 0 的地方，代表 S3 有較高下載速度。
結論：目測兩者下載速度有差異，S3 快於 imgproxy，但依據檔案大小，S3 也存在下載速度限制。
其他：檔案大小多在 2.5 MB 以下

圖2. S3 vs Imgproxy S3 下載速度

圖3. S3 vs Imgproxy S3 速度差

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 與 Imgproxy → S3 下載速度是否有差異

假設

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

方法

  1. 控制組：Akamai → S3

  2. 對照組：Imgproxy → S3

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

數據分析


圖4. CDN S3 vs Imgproxy S3 下載速度


單純使用 imgproxy 進行下載，存在速度限制 2MB，Max 2.65 MB/s (圖4)；使用 Akamai → S3 有較高的下載速度， Max 可以到 10.08 MB/s

圖5. CDN S3 vs Imgproxy S3 速度差

Speed Difference 基本上都 > 0 (圖5.)

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

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

測試三

目的

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

假設

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

方法

  1. 控制組：Akamai → S3

  2. 對照組：CloudFront → Imgproxy → S3

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

數據分析

就平均值而言，看起來有一個 Max 8MB/s 的速度限制(圖6. )

圖6. CDN S3 vs CND Imgproxy S3 下載速度


圖7. CDN S3 vs CDN Imgproxy S3 速度差


Speed Difference 明顯往 < 0 偏移

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

測試四

目的

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

方法

  1. 控制組：CloudFront → Imgproxy 第一次下載速度

  2. 對照組：
    a. CloudFront → Imgproxy → 第二次下載速度
    b. CloudFront → Imgproxy → 第三次下載速度

  3. 同一個檔案下載三次用 Wilcoxon 檢定是否存在顯著差異

  4. 假設檢定

    1. 假說（H0）：不同下載次數之間無顯著差異。

    2. 對立假說（H1）：不同下載次數之間存在顯著差異。

  5. 使用的檢定方法
    由於數據不符合常態分佈，採用 Wilcoxon 符號檢定（Wilcoxon Signed-Rank Test）。

檢定結果

圖8. 箱型圖與提琴圖的 CDN Imgproxy 第 1, 2, 3 次下載速度差

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) 是否也存在差異

圖9. 箱型圖與提琴圖的 Imgrpoxy 第 1, 2, 3 次下載速度差

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

b. 確認 CDN 緩存完全建立時性能最佳

假設

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

方法

  1. 控制組：CDN → S3

  2. 對照組：CDN → Imgproxy → S3

  3. 同一個檔案在控制組下載三次，算平均值，對照組僅下載第一次

數據分析

明顯 imgproxy 第一次的結果又回到 2MB/s (圖10.)

圖10. CDN S3 三次平均下載速度 vs CND Imgproxy S3 第一次下載速度

圖11. CDN S3 三次平均下載速度 vs CND Imgproxy S3 第一次下載速度比較

如果藍點點在紅線上表示兩者下載速度一致
結論：CDN Imgproxy 第一次下載流量會被 imgproxy 速度限制
因此看拿掉第一次下載數據，整體下載速度是否可以提升

目的

使用 CDN → Imgproxy 可有效提升下載速度。

假設

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

方法

  1. 控制組：CDN → S3

  2. 對照組：CDN → Imgproxy → S3

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

圖12. CDN S3 三次平均下載速度 vs CND Imgproxy S3 第二三次平均下載速度

結論：

在緩存建立下，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 的比較

Comments

Post a Comment

Popular posts from this blog

《 Akamai + S3 與 CloudFront + Imgproxy + S3 使用分析二：壓縮圖片設計流程：檔案大小 vs 載入時間的權衡》

Image
要透過 Imgproxy 客製化每種圖檔要被壓縮的方法，真的超難啦！ 目標 將圖片壓縮到 50 KB、250 KB、500 KB、1 MB 等不同檔案大小。 對於已小於目標大小的圖片，不進行壓縮以避免檔案變大。 支援多種圖片格式（PNG、JPG、AVIF 等），依據需求選擇最佳壓縮格式。 提供不同解析度的圖片給前端，讓前端可以根據用戶網速自動切換合適檔案大小。 壓縮設計 目的 利用 Imgproxy 壓縮圖檔下載是否可以有效增加下載圖片效率 步驟 1：判斷檔案大小與格式 從 Akamai_S3 下載原始圖片後，先檢查檔案大小與格式。 如果檔案小於欲壓縮格式目標大小 （例如欲壓縮至 250 KB，但檔案只有 70 KB），則該格式 不做處理 ，繼續跳往下一級 (50 KB)。 如果檔案大於目標大小，進行壓縮或格式轉換。 步驟 2：選擇壓縮策略與格式 優先順序： JPG (JPEG) ：適合照片、色彩豐富的圖片。壓縮率高但會有損失。 AVIF / WEBP ：壓縮率更高，幾乎無損，適合支持新格式的瀏覽器。 PNG ：適合需要透明背景的圖片。壓縮率較低但無損壓縮。 選擇策略： PNG → JPG ：如果 PNG 沒有透明背景且圖片過大，轉成 JPG 可以大幅減少檔案大小。 AVIF → AVIF ：AVIF 檔案通常已經很小，不需要轉換，僅調整品質。 JPG → JPG ：降低品質進行壓縮。 GIF → WEBP ：動態 GIF 可轉成 WEBP，通常能縮小 30-50%。 步驟 3：壓縮參數設定 JPG： quality=70-80 是較理想的平衡點， 70 可顯著減少檔案大小，畫質影響有限。 PNG： 使用無損壓縮，或轉換成 JPG 若透明度不重要。 WEBP / AVIF： quality=60-70 仍能保持優異畫質，檔案非常小。 根據以上制定規則，以下為測試參數搭配在不同檔案類型下有最佳效果的測試 png: > 1MB: q:80/rs:fit:1920:1080 500 KB - 1 MB: q:70/rs:fit:1280:720 250 KB - 500 KB: q:60/rs:fit:800:600 50 KB - 250KB: q:50/rs:fit:400:300 jpeg or jpg > 1MB: q:80/mb:1000000...
Read more

程式語言初學者 Docker 入門第二章 —— 安裝與驗證 (Mac)

Image
驗證 Docker 安裝 這邊介紹兩種安裝方式 Docker Desktop 簡單好用、好理解、易上手，請至底下連結到官網安裝 Docker Desktop for Mac and Windows | Docker 安裝完成後，可以在 Terminal 終端機下以下 command $ docker version 如果看到類似的  error message   Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? 表示沒有正常啟動，去 Application 把 Docker 打開 以下為正常顯示 Client: Cloud integration: 1.0 .14 Version: 20.10 .6 API version: 1.41 Go version: go1.16.3 Git commit: 370c289 Built: Fri Apr 9 22 : 46 : 57 2021 OS/Arch: darwin/amd64 Context: default Experimental: true Server: Docker Engine - Community Engine: Version: 20.10 .6 API version: 1.41 (minimum version 1.12 ) Go version: go1.13.15 Git commit: 8728dd2 Built: Fri Apr 9 22 : 44 : 56 2021 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.4 .4 GitCommit: 05f951a3781f4f2c1911b05e61c160e9c...
Read more