QPS 50万，我厂业务QPS 才 3000 [泪奔] 同志们也看看我们有没有这个问题。

@agentzh

在金融科技领域，核心系统的稳定性是绝对的红线。最近我们协助一家头部客户排查开源 OpenResty 网关性能时，遇到了一个极其隐蔽的场景：系统承载 50万 QPS 的巨大流量，监控显示绝大多数请求的响应时间都在 10 毫秒以内。但隐患往往藏在细节中，每天仍有约 1% 的请求响应时间超过 300 毫秒。对于核心交易链路，这意味着不可接受的超时风险。这可能是很多技术负责人最头疼的时刻：大概知道问题出在 Lua 代码层，很可能是正则匹配在空转，但不知道具体是哪一行、哪个函数，更不敢在生产环境盲目加日志或重启服务来调试。

我们利用 OpenResty XRay 对其生产环境进行了完全非侵入式的扫描，在不修改代码、不重启进程的前提下，迅速锁定了两个"隐形杀手"：

* 代码习惯陷阱：一个不起眼的 `string.gmatch` 调用，因正则引擎回溯导致单次耗时高达 244 毫秒。

* 被遗忘的配置：基础镜像编译时漏掉了 JIT 标志，导致网关在 Log 阶段为每个请求反复编译正则，白白消耗了大量 CPU。

修复后效果立竿见影：慢请求彻底消失，集群 CPU 占用率直接下降了 30%。这篇文章 网页链接 详细复盘了我们如何利用 OpenResty XRay 定位到这 244 毫秒，并排查其性能问题的全过程。

#OpenResty##OpenRestyXRay##性能优化##动态追踪#