OpenResty：通过LD_PRELOAD在ngx.ctx中记录每个请求的Lua执行时间
内容提要
本文讨论了如何在OpenResty中记录Lua执行时间，排除异步IO的影响。通过使用LD_PRELOAD，可以非侵入性地测量Lua代码的执行时间，确保高性能的业务逻辑处理。文章分析了Nginx的请求生命周期及时间记录机制，指出不同配置对时间测量的影响，并提供示例代码实现该功能。
延伸解读
为何不能简单用 $request_time 减 $upstream_respon
文章指出，$upstream_response_time 的含义会随 proxy_request_buffering 和 proxy_buffering 的配置变化。默认开启缓冲时，它只覆盖上游流量和部分下游流量；关闭缓冲后，它几乎覆盖整个下游流量。因此，直接相减无法稳定得到纯 Lua 执行时间，还可能因计时源不同出现 $request_time 小于 $upstream_response_time 的反常现象。
LD_PRELOAD 方案如何做到非侵入且低开销
该方案通过 LD_PRELOAD 挂钩 lua_resume 和 lua_pcall，在函数入口和出口用 clock_gettime 记录时间差，并写入 ngx.ctx。异步阶段统一由 lua_resume 驱动，且协程恢复被扁平化，因此计时不会重叠，也自然排除了异步 IO 等待时间。同步阶段则利用 lua_pcall 的错误处理函数特征过滤噪声，降低额外开销。
使用 LD_PRELOAD 的前提与限制
文章提醒，挂钩的 C 符号必须是公开的，且依赖方不能通过偏移量直接定位该符号；同时函数参数和返回值需包含足够信息用于分析，并能过滤无关调用上下文。此外，该方案依赖 OpenResty 内部函数名和阶段划分，若版本升级导致符号或调用方式变化，可能需要同步调整。
实际部署与验证方式
文章给出示例：通过环境变量 NGX_LUA_REQUEST_TIME_VAR_NAME 指定 ngx.ctx 中的变量名，并用 LD_PRELOAD 加载动态库。在 access_by_lua_block 中调用 libc 的 sleep(1) 后，log_by_lua_block 输出的 openresty_request_time_us 约为 1000120 微秒，验证了阻塞时间被正确记录。该库也可通过 /etc/ld.so.preload 全局启用，便于容器环境使用。
Q&A
如何在OpenResty中记录Lua代码的执行时间？
可以通过使用LD_PRELOAD来非侵入性地测量Lua代码的执行时间，确保高性能的业务逻辑处理。
LD_PRELOAD在记录Lua执行时间中有什么优势？
LD_PRELOAD可以避免对性能的显著影响，并且提供了一种非侵入性的方式来记录Lua执行时间。
Nginx的$request_time和$upstream_response_time有什么区别？
$request_time是从客户端读取第一个字节开始到请求完成的时间，而$upstream_response_time是从Nginx向上游服务器发送请求到接收到响应的时间。
如何通过示例代码实现Lua执行时间的记录？
文章提供了示例代码，使用LD_PRELOAD和ngx.ctx.openresty_request_time_us来记录Lua执行时间。
在OpenResty中，如何确保业务逻辑的高性能处理？
通过充分利用异步API和使用LD_PRELOAD来记录Lua执行时间，可以确保高性能的业务逻辑处理。
Nginx的请求生命周期是怎样的？
Nginx的请求生命周期包括多个阶段，如重写、访问、内容处理等，每个阶段的处理顺序和时间记录机制会影响最终的请求时间。
