背景與挑戰
科技博客 GigaOM 曾報道：YouTube 的視頻略縮圖採用 WebP 格式後，網頁加載速度提升了 10%；谷歌的 Chrome 網上應用商店採用 WebP 格式圖片後，每天可以節省幾 TB 的帶寬，頁面平均加載時間大約減少 1/3；Google+ 移動應用採用 WebP 圖片格式後，每天節省了 50TB 數據存儲空間。但Webp最大的缺點在於壓縮算法計算複雜度是JPEG的10倍以上，我們迫切需要一套高性能加速方案來降低業務成本。
項目
今年春節期間大客戶爲了支持其搶紅包業務向阿里雲提出了webp轉碼需求。根據以往經驗總共需要準備數幾十臺32核64線程的物理機。阿里云爲提升用戶體驗降低自身成本，使用FaaS（FPGA as a Service） F1實例加速webp編碼。其中FaaS團隊提供了FPGA平臺支持，OSS團隊提供了算法的支持。得益於高性能的FPGA平臺，我們使用5臺單卡FPGA雲服務器扛下了日常40%的webp編碼流量。
效果
本次性能測試所使用樣本爲512x512的圖片，所有測試都在阿里雲FaaS F1實例上測試。根據業務方的要求，我們對其中部分數據值做了一些混淆。
1）延時
在使用了FPGA加速webp編碼之後，延遲降爲原來的1/10。
2）吞吐量
每個單卡的F1實例（8vcpu，1 * ARRIA 10)可以獲得大約32核64線程物理機的~2倍吞吐量，跟某業內專業加速webp編碼公司對比（在用同樣F1實例）。我們發現某司的FPGA加速webp編碼對CPU依賴非常多，但利用率又只有50-60%，這非常讓人費解。
3）圖片質量
下圖是在不同quality下，對比軟件（藍線）、OSS（紅線）、某司（綠線）的編碼後psnr曲線。PSNR使用ImageMagick的convert工具計算，數值越大越好。OSS提供的硬件加速算法，在圖像質量方面幾乎跟軟件幾乎完全重合，某司提供的webp編碼加速器存在不小的差距（差距在0.1~0.5db之間）。
4)壓縮率
同樣使用圖片空間的測試架，quality設置也一樣，數值爲相對JPEG原圖的壓縮率，數值越小越好。經過測試我們發現軟件、OSS、某司的壓縮率幾乎完全重合，但依舊保持原有梯隊，軟件>OSS>某司。
根據上面測試結果，目前阿里雲OSS的加速方案在webp壓縮場景所有指標都超過了某司，除了壓縮率小幅領先之外，其他兩個指標都有非常明顯的優勢。
未來
1）預計性能優化完成之後E2E還可以提升50%的性能。壓縮率上，未來採用m6等級的編碼，其壓縮率比當前壓縮率更高。
2）單個FPGA板卡的成本遠小於服務器，所以降低業務成本的關鍵在於提高FPGA的密度。未來webp加速器將使用F3實例，單個芯片的FPGA性能提升了超過2倍，單臺服務器的FPGA芯片密度也提升了一倍。
本文作者：
原文鏈接：https://yq.aliyun.com/articles/561260?spm=a2c41.11181499.0.0