APISIX运维优化之解决长尾请求（耗时抖动）问题

自从 APISIX 网关推广使用以来，在我们部门已经有很多生产业务接入使用。有一天被拉进了一个问题群，被告知 APISIX 网关性能有问题，整体表现还不如之前的 ZUUL 网关。纳尼？APISIX 性能再怎么不济也不至于比 ZUUL 差吧？

废话少说，直接上手弄了个串行请求对比测试了一下生产环境的 APISIX 网关和 ZUUL 网关，结果大跌眼镜！

正常情况下，APISIX 的耗时都优于 ZUUL 网关，但是 APISIX 偶尔会来一次很高的延迟，如下图所示：

很明显，APISIX 偶尔会出现明显大于正常延迟超过 10 倍的超高延迟！

先说下解决办法：

以下是官方解释：

以下是部分分析过程，感兴趣的可以看看：

把我们自己开发的插件都关闭试了下，发现这个现象依然存在，于是我整理了一个可复现 case 提交到了 APISIX 官方：bug: The latency of request is not stable as expected · Issue #5604 · apache/apisix (github.com)

提交 issue 之后，APISIX 官方非常给力（效率爆赞），院生大佬亲自发邮件让我微信联系（相当亲民），然后当天就拉群沟通了：

第一时间，APISIX 开发同学拿我整理的 case 用例，发现确实有部分延迟不正常：

然后，通过 Nginx 试了下， 发现情况类似：

最终，结论认定在测试用例下未复现异常。然后，我自己也在测试环境对比测试了下，确实和 Nginx 表现接近，没有明显异常情况。但是请求现网就会明显的延迟飙升现象。于是在现网环境也部署了一套 Nginx 代理试了下， 来排除网络问题，发现完全没有任何问题。甚至直接在 APISIX 容器内部发起本地请求也会存在飙升问题，因此和网络应该没关系了。

注：这过程发现一个有意思的现象：虽然延迟飙升，但是 APISIX 的日志记录的 latency 却很低。

再后来几乎就没有什么新的想法了，官方建议装个 openresty-xray 分析下火焰图什么的，结果在腾讯 tlinux 系统里面还挺麻烦，没继续花时间折腾。

最后，实在没办法了，凭着最后一点倔强，我在个人腾讯云公有云账号里面参考现网环境复刻了一套 APISIX（弹性集群），结果用 wrk2 测试后 APISIX 直接挂掉了，重启容器才能恢复，我去？？？

看来，接近真相了。简单分析了下，应该是在公有云里面 APISIX 里面有插件和内网不通，比如自研日志插件和服务发现插件，导致请求堆积了。进而，我试了下禁用日志插件，发现就没问题了。

根据这个提示，灵光一闪，尝试把以下配置全部注释试了下：

plugin_attr:
  prometheus:
    export_uri: /apisix/prometheus/metrics
    enable_export_server: true
    export_addr:
      ip: 0.0.0.0
      port: 9091
  server-info:
    report_interval: 60
    report_ttl: 3600

zhiyan_log:
  env: idc
  topic: default
  proto: udp
  max_batch_number: 500
  max_report_time: 2

discovery:
  eureka:
    host:
      - http://xxxxx
      
    prefix: "/eureka/"
    fetch_interval: 5
    weight: 100
    timeout:
      connect: 2000
      send: 2000
      read: 5000

  polaris:
     cache_size: 1000
     update_time: 3
     max_cache_time: 5

结果，延迟问题消失了？！消失了？！

好吧，这就简单了，把上述插件一项一项放开测试，最终发现是 prometheus 开启后导致延迟抖动，当然只是开启是没问题的，我停止 prometheus 的拉取，卡顿问题也立马消失了：

目前官方已经对prometheus 插件发起了优化讨论：[DISCUSS]: Improving the performance of the prometheus plugin · Issue #5755 · apache/apisix (github.com)，我们就只能静待官方的优化版本了，只是这期间，我们的网关就只能先 L 奔了。