veImageX演进之路:FPGA HEIF 静图编码服务性能优化

图像处理

压缩技术对于图像、视频应用十分重要。在保证同样主观质量的前提下,如何将图像压缩到更小体积,以便于互联网信息传输,火山引擎视频云团队不断突破压缩技术“天花板”。

字节跳动在公司成立之初便建设了图像处理平台,起初主要服务于今日头条APP的图文资源。随着业务扩展,后逐步服务于抖音图集、短视频封面、图虫等用户几乎能看到的所有图片展示场景。火山引擎视频云团队将字节跳动图像处理的实践,整理为《 veImageX 演进之路》系列,将从产品应用、后端技术、前端技术、算法、客户端 SDK 详细解读字节跳动背后的图像技术。

veImageX是火山引擎基于字节跳动内部服务实践,推出的图像一站式解决方案 ,覆盖上传、存储、处理、分发、展示、质量监控全链路应用。

背景

互联网内容的展示离不开图片,通过 CDN 展示分发图片可以提升图片访问速度,但是也需要为带宽付费。HEIF 图片格式有着卓越的压缩性能,相比 WebP 可节省 30% 的图片码率,由此能够为业务节省相当规模的带宽成本。

但 HEIF 格式是一把双刃剑,相比其他格式,在提升压缩率的同时,也需要消耗更多 CPU 计算资源。为了降低 HEIF 格式的编码计算成本,veImageX 采用了FPGA异构架构,逐步将 HEIF 编码的流量从 CPU 计算集群迁移到 FPGA 计算集群。

在流量迁移过程中,最初整体流量较小,FPGA 编码服务看起来很稳定。但随着迁移过程递进,当 FPGA 的单卡 QPS 上涨到一定阈值后,FPGA 卡所在宿主机的性能瓶颈逐渐暴露出来,从而影响整体的迁移工作。

本文会对迁移过程中遇到的性能瓶颈进行分析,并给出优化解决方案。经过一系列的优化措施,veImageX 整体 CPU 负载从80%降低至30%,相应的服务延时从140ms降低为4ms。

架构

首先,我们看一下 FPGA HEIF 静图分发链路的整体架构。

picture.image 链路分为三块:

  • 业务 App:一般会集成 veImageX 的图片 SDK。既可以兼容各类图片格式(自然也包括 HEIF),提供图片的下载、解码、展示功能。也支持将访问图片过程中产生的指标数据上报,以便于在控制台查看这些性能指标,比如解码耗时、图片加载成功率等。
  • veImageX 分发基础链路:主要解决图片分发问题,提供基础的图片实时处理能力。其中 CDN 缓存了图片请求,提供加速访问的能力;veImageX 源站服务主要负责访问权限的校验、流量控制、图片资源下载以及静态图片的主体处理流程。对于 HEIF 静图编码场景,veImageX 源站服务则需要和 FPGA HEIF 编码服务互动,协作完成。
  • FPGA HEIF 编码服务:自上而下可分为编码服务层、编码驱动层、编码硬件层。

为了解决计算资源异构引入的耦合问题,FPGA HEIF 编码能力通过 HTTP 服务化的方式提供出来。所有的 FPGA 卡部署于字节跳动自研的Lambda计算平台。通过 Lambda 函数+资源虚拟化的方式,将 HEIF 编码功能抽象为上游可直接调用的服务,并且能够确保将编码请求均衡地调度到各个 FPGA 卡上。物理机上的每一张 FPGA 卡和对应的主机 CPU 以及内存资源都被打包,经由 Executor 管理。此外,为了防止 FPGA 卡被突发流量打挂,Executor 内置了一个执行队列,用于控制 FPGA 卡的并发吞吐。

编码服务层主要负责解析 HTTP 请求,获取待编码的图片数据。待编码的图片数据一般通过 JPEG 格式传入,因此其中内嵌了一个 JPEG 解码器。此外,veImageX HEIF 支持自适应编码选项,通过服务层内的自适应模型预测编码所用到的质量参数。服务层中的 HEIF 编码器是一个适配层,屏蔽了底层计算架构的差异,对于 CPU 和 FPGA 都可以提供相同的编码接口,将传入的 RGBA 像素矩阵编码为 HEIF 码流。

编码驱动层中的 FBVC1 编码器可以将图片像素序列编码为二进制码流,上层的 HEIF 编码器拿到这个码流后,按照 HEIF 标准格式封装即可。FBVC1 编码过程中,依赖了 FPGA 驱动库和编码硬件层打交道,发送指令,读写 FPGA 设备。

优化方向

降低线程数在迁移测试FPGA编码服务过程中,我们也遇到了一些性能瓶颈的问题。首当其冲的是,当单机 QPS 达到 2K 时,CPU 负载高达到 60%。通过分析热点,我们可以看到问题出现在 onnxruntime 这个库上。

picture.image

从调用的 API 很容易联想到,这是一个线程相关问题。我们都知道,如果没有手动设置线程数的话,默认会使用物理机核数作为线程数,导致整体的调度开销较为严重。

因此,需要根据宿主机的CPU配置情况,手动配置线程数,不要使用默认配置,最终将 CPU 负载从 57% 降低到 7%。

调优 GOMAXPROCSHEIF 的编码服务层是使用 Golang 实现的。而 Golang 中使用了 GOMAXPROCS 这个环境编码来控制底层并发度。

默认情况下,GOMAXPROCS 与物理机核数相关。所以这里也遇到了和上一个问题相同的根因,需要限制整体的并发度。针对 GOMAXPROCS 进行调优,在单机 QPS 达到 8K 时,CPU 负载下降 6% 。

限制磁盘 IO

首先通过 statio 查看磁盘情况:

picture.image

再结合下面的火焰图(黑框内有明显的磁盘 IO 操作):

picture.image

这里能够很容易想到,这些磁盘 IO 操作导致了整体延迟的升高。但从结果来看,平均 8ms 还在预期范围内。但 HEIF 编码服务对处理的延迟要求较为严格,请求处理过慢会导致请求堆积,此时 FPGA 的计算潜力无法做到完全释放。

针对这部分定向优化,相关延时下降至 0.5ms,CPU 负载下降 3%。

另外,我们观察到磁盘和 cached memory 较高,这显然不太正常。

picture.image

picture.image

进一步定位后,确定是编码服务造成的。详细排查后发现,编码驱动层中的 FPGA 驱动程序,部分调试日志未关闭,导致大量的日志写磁盘。当关闭驱动的调试日志后,CPU 负载下降 5% 。

合并 CGO 调用编码服务包括两部分的 CGO 调用:

  • 自适应编码模型预测:每个请求会有最多 5 次的推理,合并为 Batch,减少为 1 次调用;
  • FPGA 编码:直接调用 SDK 需要 6 次 CGO 调用,对这部分实现 C 的封装,减少为 2 次调用。

这部分优化影响较小,在延迟数据层面不是很明显,模型预测部分可能有几百 us 的优化。

减少 GC

编码服务每次处理请求都需要获取图像 raw data,因此服务会多次创建 []byte 的图像数据对象,容易导致频繁 GC。

一个解决问题的思路是在服务启动前,预分配一个固定的对象池,每次请求需要的 []byte 对象直接从对象池里中选取。此外,也曾尝试过使用 Golang 标准库中的 sync.Pool,但效果不好,可能是因为 sync.Pool 中依然有一些 GC 相关的策略,不符合我们这个场景。

这部分优化后,CPU 负载下降6% 。

均衡中断

从系统的监控中,我们观察到各 CPU 负载不是很均匀。

picture.image

picture.image

编码过程中发生的中断情况

我们可以得出结论,FPGA 的相关中断被只绑定到了特定的 CPU 上,没有分布均匀。这个在当时并没有成为瓶颈,所以优化后没有明显提升。

加速图片解码

我们从火焰图可以看到解码时间占服务延时的较大部分。

picture.image

对火焰图中黑框内调用栈分析后,观察到有相当部分时间消耗在了 JPEG 解码上。调查后,发现底层 SDK 解码使用了 libjpeg,整体性能不佳。这里我们替换为使用 SIMD 实现的 libjpeg-turbo 解码库后,CPU 负载降低了 10%,耗时减少 2ms。

优化总结

基于优化后的版本再次做性能压测,使用 300x400 分辨率的测试图片,当单机 QPS 达到 10K 时,编码服务整体性能指标变化如下:

  • CPU 负载从 80% 降低为 30%;
  • 服务延时从 140ms 降低为 4ms。

可以看到,经过我们一套“组合拳”优化后,整体编码服务的性能有了明显提升。

写在最后

目前火山引擎 veImageX已经基于上述实践,形成端到端的解决方案对外输出,帮助每一个互联网企业用更低的成本达到更好的图片加载效果。除商务降本之外,也可以用更“绿色”的算法降本,为行业降本增效提供了一种全新可能。

0
0
0
0
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论