发表于 2024年9月4日1年前 整体服务是两套 openresty A/B然后有几个变量：A 的 resty-http 的请求超时时间 a_timeoutB 定时同步规则的时间间隔 b_intervalA 使用 resty-http 向 B 发起 http 请求拿响应；B 使用 ffi 加载 golang 编译的 c-shared 的 so 包，接收到 A 的请求后把请求塞进 so 里用倒数函数 detect 拿结果，在 init_worker 阶段起了个 timer ，每隔 b_interval 拉一次数据并同步到每个 worker 加载的 so ，通过导出函数 update 。现象：A 上每隔 b_interval 的时间都会出现一波超时，但是我在 B 的 log 阶段，ngx.update_time()后打印了请求的完整耗时 ngx.now()-ngx.req.start_time()，几乎没有超过 a_timeout 的。目前能排查出来的可能问题应该是导出函数 update 可能有问题，但是如果因为它阻塞了，那在 log 阶段打印请求耗时应该和 A 上的表现一直才对？求指教
然后有几个变量：
A 的 resty-http 的请求超时时间 a_timeout
B 定时同步规则的时间间隔 b_interval
A 使用 resty-http 向 B 发起 http 请求拿响应；
B 使用 ffi 加载 golang 编译的 c-shared 的 so 包，接收到 A 的请求后把请求塞进 so 里用倒数函数 detect 拿结果，在 init_worker 阶段起了个 timer ，每隔 b_interval 拉一次数据并同步到每个 worker 加载的 so ，通过导出函数 update 。
现象：A 上每隔 b_interval 的时间都会出现一波超时，但是我在 B 的 log 阶段，ngx.update_time()后打印了请求的完整耗时 ngx.now()-ngx.req.start_time()，几乎没有超过 a_timeout 的。
目前能排查出来的可能问题应该是导出函数 update 可能有问题，但是如果因为它阻塞了，那在 log 阶段打印请求耗时应该和 A 上的表现一直才对？求指教