異構計算助力客戶春節webp圖片編碼

摘要： 背景與挑戰 技博客 GigaOM 曾報道：YouTube 的視頻略縮圖採用 WebP 格式後，網頁加載速度提高了 10%；谷歌的 Chrome 網上應用商店採用 WebP 格式圖片後，天天能夠節省幾 TB 的帶寬，頁面平均加載時間大約減小 1/3；Google+ 移動應用採用 WebP 圖片格式後，天天節省了 50TB 數據存儲空間。

 

背景與挑戰

 

科技博客 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芯片密度也提高了一倍。

 

原文連接

閱讀更多幹貨好文，請關注掃描如下二維碼：