vlambda博客
学习文章列表

利用火焰图优化基于openresty服务的性能

上一篇我们讲述了,介绍了实现该方案需要进行的改造内容。在实现完这套新的方案后,提供给识别团队改造内核的同事做压测,压测下来新方案的性能有不少的提升,同时我这边也对重构完的casrserver做了一些性能的优化。

casrserver是基于openresty的一个长连接服务,对外提供基于websocket协议的接口, 支持实时的语音流上行,casrserver和识别内核服务通过自定义的tcp协议进行通信。 

开了4个worker, 在 Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz 的cpu上400个并发连接做识别的测试(之所以是400个并发是因为单个asr-kernel-server支持的识别并发上限就是400左右)。

问题1

一开始测试的时候,发现4个worker的负载不是很均衡,有一个worker的cpu使用率会到40%多。

通过排查,发现之前的单worker方案,不需要开启reuseport, 我们修改了一下nginx配置,开启了reuseport,这个配置可以减少worker之间获取新连接时的锁竞争,具体介绍可以看这篇

继续压测,casrserver每个worker的cpu的负载基本均衡了,每个占用大约在30%, 与此同时,从同事的测试结果来看,这个参数的优化给识别带来了10ms左右的延时提升。

问题2

同事将我修改完打包好的csarserver镜像部署到自己的服务器上进行压测的时候,发现同样400个并发, cpu占用会高达50%多, 看了一下机器配置,这台服务器有48个核,cpu是Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz, 看上去主频比我自测的机器低了一些。于是我准备抓个火焰图看看cpu的占用都在哪里,看看有没有优化的空间。

在抓取前需要做一些准备工作,具体参照《openresty最佳实践》中关于如何安装火焰图生成工具的步骤。

值得一提的是安装systemtap完后,执行测试的时候出现了如下的报错

1
fatal error: runtime_defines.h: No such file or directory

需要安装一下systemtap-devel。

抓了30s的压测数据,最终得到了如下的火焰图:

从火焰图可以看到,49%的cpu消耗在lua-resty-websocket库的recv_frame函数中,还有36.44%的cpu消耗在我们自己的recv协程中,其中32%在封装的unpack函数中,进一步的看到一个简单的unpack_prefix函数竟然占用了11.46%的cpu, 预感是这里有优化空间。
贴一下这个函数的实现

1
2
3
4
5
6
7
8
9
10
11
12
local prefix = {byte(data, 1, 8)}
for i = 1, 4 do
if band(0xA5, prefix[i]) ~= 0 then
return nil, "bad prefix"
end
end
for i = 5, 8 do
if band(0x5A, prefix[i]) ~= 0 then
return nil, "bad prefix"
end
end
return true

修改后直接简化为:

1
2
3
4
local function unpack_prefix(data)
local received_prefix = string.sub(data, 1, 8)
return received_prefix == protocol_prefix
end

同时排查protocol.lua中类似的代码,然后写了一个benchmark的脚本进行比较

做了100w次的测试, 得到了protocol.lua中6个函数的耗时比较:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ /usr/local/openresty/bin/resty benchmark.lua
======== BENCHMARK 1 ===============
========benchnark unpack_prefix: 12930.000066757 ms
========benchnark unpack_reserved: 12336.999893188 ms
========benchnark unpack_payload_length: 0.99992752075195 ms
========benchnark pack_reserved: 0 ms
========benchnark pack_prefix: 61.000108718872 ms
========benchnark pack_payload_length: 59.999942779541 ms
======== BENCHMARK 2 ===============
========benchnark unpack_prefix: 0.99992752075195 ms
========benchnark unpack_reserved: 0 ms
========benchnark unpack_payload_length: 1.0001659393311 ms
========benchnark pack_reserved: 0 ms
========benchnark pack_prefix: 0.99992752075195 ms
========benchnark pack_payload_length: 0 ms

可以看到unpack_prefix和unpack_reserved两个函数性能相差巨大,确认这块代码没问题后,重新进行了压测,得到的火焰图如下



可以看到websocket库cpu占用的比例进一步提升,recv协cpu的占用下降了约15%。打包服务后并发压每个worker的cpu下降了约5%。

问题3

经过上面的优化,火焰图中cpu的消耗主要集中到了recv_frame这个函数上,我们项目里使用的是openresty 官方提供的lua-resty-websocket库,于是我们准备找找这个库有没有可以优化的地方。

我们先来讲一下这个websocket库,源码分为3个文件分别是protocol.lua, server.lua和client.lua。其中protocol.lua实现了websocket的协议,client.lua封装了作为客户端的api,server.lua 封装了作为服务端的api。

从火焰图里可以看到性能主要消耗在protocol.lua 封装的recv_frame里面,在代码里找到了两个for循环,都是在对mask报文做计算,解析出原始报文。熟悉websocket协议的朋友都知道,websocket协议里规定了client -> server的payload报文需要进行mask处理,websocket协议的介绍可以看这篇websocket协议解读

同时代码里也写了一个TODO, 用luajit的string.buffer进行优化:

1
2
3
4
5
6
7
-- TODO string.buffer optimizations
local bytes = new_tab(payload_len, 0)
for i = 1, payload_len do
bytes[i] = str_char(bxor(byte(data, 4 + i),
byte(data, (i - 1) % 4 + 1)))
end
msg = concat(bytes)

于是我们开始寻找luajit的string.buffer api的实现,不幸的是找了一遍openresty维护的luajit库,也没有找到string.buffer的API。于是我们准备自己动手,尝试用ffi string 替换掉当前这段代码的实现,同时写了benchmark的代码在这里

1
2
3
$ /usr/local/openresty/bin/resty test.lua
=========benchmark1 cost:6322.9999542236 ms.
=========benchmark2 cost:720.00002861023 ms.

从结果看,执行了10w次的masked payload计算,我们发现ffi string版本的实现相较于原来的版本,性能上有8-10倍的提升。于是我们替换了官方的库再次进行压测,400并发,每个worker的cpu又下降了5%左右。同时从抓到的火焰图看recv_frame的比例下降到了22.4%。

修改后的ffi string版本的lua-resty-websocket库, 已经给官方仓库提交了PR。到此carserver性能优化工作也告一段落,不得不感叹,systemtap结合火焰图真的是排查openresty写的服务性能问题的神兵利器。