当前位置: 首页 > 工具软件 > lua-resty-ffi > 使用案例 >

OpenResty从入门到精通09-为什么lua-resty-core性能更高一些?

齐建安
2023-12-01

09 | 为什么 lua-resty-core 性能更高一些?

你好,我是温铭。

前面两节课我们说了,Lua 是一种嵌入式开发语言,核心保持了短小精悍,你可以在 Redis、NGINX 中嵌入 Lua,来帮助你更灵活地完成业务逻辑。同时,Lua 也可以调用已有的 C 函数和数据结构,避免重复造轮子。

在 Lua 中,你可以用 Lua C API 来调用 C 函数,而在 LuaJIT 中还可以使用 FFI。对 OpenResty 而言:

  • 在核心的 lua-nginx-module 中,调用 C 函数的 API,都是使用 Lua C API 来完成的;
  • 而在 lua-resty-core 中,则是把 lua-nginx-module 已有的部分 API,使用 FFI 的模式重新实现了一遍。

看到这里你估计纳闷了:为什么要用 FFI 重新实现一遍?

别着急,让我们以 ngx.base64_decode 这个很简单的 API 为例,一起看下 Lua C API 和 FFI 的实现有何不同之处,这样你也可以对它们的性能有个直观的认识。

Lua CFunction

我们先来看下, lua-nginx-module 中用 Lua C API 是如何实现的。我们在项目的代码中搜索 decode_base64,可以找到它的代码实现在 ngx_http_lua_string.c 中:

lua_pushcfunction(L, ngx_http_lua_ngx_decode_base64);
lua_setfield(L, -2, "decode_base64");

上面的代码看着就头大,不过还好,我们不用深究那两个 lua_ 开头的函数,以及它们参数的具体作用,只需要知道一点——这里注册了一个 CFunction: ngx_http_lua_ngx_decode_base64, 而它与 ngx.base64_decode 这个对外暴露的 API 是对应关系。

我们继续“按图索骥”,在这个 C 文件中搜索 ngx_http_lua_ngx_decode_base64,它定义在文件的开始位置:

static int ngx_http_lua_ngx_decode_base64(lua_State *L);

对于那些能够被 Lua 调用的 C 函数来说,它的接口必须遵循 Lua 要求的形式,也就是 typedef int (*lua_CFunction)(lua_State* L)。它包含的参数是 lua_State 类型的指针 L ;它的返回值类型是一个整型,表示返回值的数量,而非返回值自身。

它的实现如下(这里我已经去掉了错误处理的代码):

static int
 ngx_http_lua_ngx_decode_base64(lua_State *L)
 {
     ngx_str_t p, src;

    src.data = (u_char *) luaL_checklstring(L, 1, &src.len);

     p.len = ngx_base64_decoded_length(src.len);

     p.data = lua_newuserdata(L, p.len);

     if (ngx_decode_base64(&p, &src) == NGX_OK) {
         lua_pushlstring(L, (char *) p.data, p.len);

     } else {
         lua_pushnil(L);
     }

     return 1;
 }

这段代码中,最主要的是 ngx_base64_decoded_lengthngx_decode_base64, 它们都是 NGINX 自身提供的 C 函数。

我们知道,用 C 编写的函数,无法把返回值传给 Lua 代码,而是需要通过栈,来传递 Lua 和 C 之间的调用参数和返回值。这也是为什么,会有很多我们一眼无法看懂的代码。同时,这些代码也不能被 JIT 跟踪到,所以对于 LuaJIT 而言,这些操作是处于黑盒中的,没法进行优化。

LuaJIT FFI

而 FFI 则不同。FFI 的交互部分是用 Lua 实现的,这部分代码可以被 JIT 跟踪到,并进行优化;当然,代码也会更加简洁易懂。

我们还是以 base64_decode 为例,它的 FFI 实现分散在两个仓库中: lua-resty-corelua-nginx-module。我们先来看下前者里面 实现的代码

ngx.decode_base64 = function (s)
     local slen = #s
     local dlen = base64_decoded_length(slen)

     local dst = get_string_buf(dlen)
     local pdlen = get_size_ptr()
     local ok = C.ngx_http_lua_ffi_decode_base64(s, slen, dst, pdlen)
     if ok == 0 then
         return nil
     end
     return ffi_string(dst, pdlen[0])
 end

你会发现,相比 CFunction,FFI 实现的代码清爽了很多,它具体的实现是 lua-nginx-module 仓库中的 ngx_http_lua_ffi_decode_base64,如果你对这里感兴趣,可以自己去查看这个函数的实现,特别简单,这里我就不贴代码了。

不过,细心的你,是否从上面的代码片段中,发现函数命名的一些规律了呢?

没错,OpenResty 中的函数都是有命名规范的,你可以通过命名推测出它的用处。比如:

  • ngx_http_lua_ffi_ ,是用 FFI 来处理 NGINX HTTP 请求的 Lua 函数;
  • ngx_http_lua_ngx_ ,是用 Cfunction 来处理 NGINX HTTP 请求的 Lua 函数;
  • 其他 ngx_lua_ 开头的函数,则分别属于 NGINX 和 Lua 的内置函数。

更进一步,OpenResty 中的 C 代码,也有着严格的代码规范,这里我推荐阅读 官方的 C 代码风格指南。对于有意学习 OpenResty 的 C 代码并提交 PR 的开发者来说,这是必备的一篇文档。否则,即使你的 PR 写得再好,也会因为代码风格问题被反复评论并要求修改。

关于 FFI 更多的 API 和细节,推荐你阅读 LuaJIT 官方的教程文档。技术专栏并不能代替官方文档,我也只能在有限的时间内帮你指出学习的路径,少走一些弯路,硬骨头还是需要你自己去啃的。

LuaJIT FFI GC

使用 FFI 的时候,我们可能会迷惑:在 FFI 中申请的内存,到底由谁来管理呢?是应该我们在 C 里面手动释放,还是 LuaJIT 自动回收呢?

这里有个简单的原则:LuaJIT 只负责由自己分配的资源;而 ffi.C 是 C 库的命名空间,所以,使用 ffi.C 分配的空间不由 LuaJIT 负责,需要你自己手动释放。

举个例子,比如你使用 ffi.C.malloc 申请了一块内存,那你就需要用配对的 ffi.C.free 来释放。LuaJIT 的官方文档中有一个对应的示例:

local p = ffi.gc(ffi.C.malloc(n), ffi.C.free)
 ...
 p = nil -- Last reference to p is gone.
 -- GC will eventually run finalizer: ffi.C.free(p)

这段代码中, ffi.C.malloc(n) 申请了一段内存,同时 ffi.gc 就给它注册了一个析构的回调函数 ffi.C.free。这样一来, p 这个 cdata 在被 LuaJIT GC 的时候,就会自动调用 ffi.C.free,来释放 C 级别的内存。而 cdata 是由 LuaJIT 负责 GC的 ,所以上述代码中的 p 会被 LuaJIT 自动释放。

这里要注意,如果你要在 OpenResty 中申请大块的内存,我更推荐你用 ffi.C.malloc 而不是 ffi.new。原因也很明显:

  1. ffi.new 返回的是一个 cdata,这部分内存由 LuaJIT 管理;
  2. LuaJIT GC 的管理内存是有上限的,OpenResty 中的 LuaJIT 并未开启 GC64 选项,所以 单个 worker 内存的上限只有2G。一旦超过 LuaJIT 的内存管理上限,就会导致报错。

在使用 FFI 的时候,我们还需要特别注意内存泄漏的问题。不过,凡人皆会犯错,只要是人写的代码,百密一疏,总会出现 bug。那么,有没有什么工具可以检测内存泄漏呢?

这时候,OpenResty 强大的周边测试和调试工具链就派上用场了。

我们先来说说测试。在 OpenResty 体系中,我们使用 Valgrind 来检测内存泄漏问题。

前面课程我们提到过的测试框架 test::nginx,有专门的内存泄漏检测模式去运行单元测试案例集,你只需要设置环境变量 TEST_NGINX_USE_VALGRIND=1 即可。OpenResty 的官方项目在发版本之前,都会在这个模式下完整回归,后面的测试章节中我们再详细介绍。

而 OpenResty 的 CLI resty 也有 --valgrind 选项,方便你单独运行某段 Lua 代码,即使你没有写测试案例也是没问题的。

再来看调试工具。

OpenResty 提供 基于 systemtap 的扩展,来对 OpenResty 程序进行活体的动态分析。你可以在这个项目的工具集中,搜索 gc 这个关键字,会看到 lj-gclj-gc-objs 这两个工具。

而对于 core dump 这种离线分析,OpenResty 提供了 GDB 的工具集,同样你可以在里面搜索 gc,找到 lgclgcstatlgcpath 三个工具。

这些调试工具的具体用法,我们会在后面的调试章节中详细介绍,你先有个印象即可。这样,你遇到内存问题就不会“病急乱投医“,毕竟OpenResty 有专门的工具集,帮你定位和解决这些问题。

lua-resty-core

从上面的比较中,我们可以看到,FFI 的方式不仅代码更简洁,而且可以被 LuaJIT 优化,显然是更优的选择。其实现实也是如此,实际上,CFunction 的实现方式已经被 OpenResty 废弃,相关的实现也从代码库中移除了。现在新的 API,都通过 FFI 的方式,在 lua-resty-core 仓库中实现。

在 OpenResty 2019 年 5 月份发布的 1.15.8.1 版本前, lua-resty-core 默认是不开启的,而这不仅会带来性能损失,更严重的是会造成潜在的 bug。所以,我强烈推荐还在使用历史版本的用户,都手动开启 lua-resty-core。你只需要在 init_by_lua 阶段,增加一行代码就可以了:

require "resty.core"

当然,姗姗来迟的 1.15.8.1 版本中,已经增加了 lua_load_resty_core 指令,默认开启了 lua-resty-core。我个人感觉,OpenResty 对于 lua-resty-core 的开启还是过于谨慎了,开源项目应该尽早把类似的功能设置为默认开启。

lua-resty-core 中不仅重新实现了部分 lua-nginx-module 项目中的 API,比如 ngx.re.matchngx.md5 等,还实现了不少新的 API,比如 ngx.ssl、ngx.base64、ngx.errlog、ngx.process、ngx.re.split、ngx.resp.add_header、ngx.balancer、ngx.semaphore 等等,我们在后面的 OpenResty API 章节中会介绍到。

写在最后

讲了这么多内容,最后我还是想说,FFI 虽然好,却也并不是性能银弹。它之所以高效,主要原因就是可以被 JIT 追踪并优化。如果你写的 Lua 代码不能被 JIT,而是需要在解释模式下执行,那么 FFI 的效率反而会更低。

那么到底有哪些操作可以被 JIT,哪些不能呢?怎样才可以避免写出不能被 JIT 的代码呢?下一节我来揭晓这个问题。

最后,给你留一个需要动手的作业题:你可以找一两个lua-nginx-module 和 lua-resty-core 中都存在的 API,然后性能测试比较一下两者的差异吗?你可以看下 FFI 的性能提升到底有多大。

欢迎留言和我分享你的思考、收获,也欢迎你把这篇文章分享给你的同事、朋友,一起交流,一起进步。

 类似资料: