摘要： 背景与挑战 技博客 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芯片密度也提升了一倍。
原文链接：https://yq.aliyun.com/articles/561260?spm=a2c41.11181499.0.0