HAProxy与Wildfly、Jetty上New Relic代理的响应时间差异排查求助

核心差异根源：统计口径与链路范围不同 #

首先明确两者的时间统计边界：

• HAProxy的响应时间是从接收客户端请求第一个字节到发送响应最后一个字节的全链路总时长，包含网络传输、HAProxy队列等待、Jetty处理、EJB调用、数据库交互所有环节
• Jetty上New Relic的响应时间是Jetty接收到完整请求到返回响应的处理时长，不包含HAProxy到Jetty的网络延迟、HAProxy端的队列等待时间

1. HAProxy自身队列与连接瓶颈 #

• 检查HAProxy实时队列指标：执行echo "show stats" | socat stdio /var/run/haproxy.sock查看qcur（当前排队请求数）、qmax（历史最大排队数），若数值持续不为0，说明请求在HAProxy端堆积，这部分等待时间会被HAProxy统计，但不会进入Jetty的New Relic监控
• 验证连接数配置：检查HAProxy的maxconn参数是否低于客户端并发峰值，当并发超过阈值时，新请求会被放入队列等待，直接拉长总响应时间
• 分析HAProxy日志：启用option httplog并添加%T（总响应时间）、%TR（请求转发到Jetty的耗时）、%Tw（Jetty处理耗时）字段，通过对比这三个值，直接定位是队列等待还是网络延迟导致的差异

2. 网络层传输延迟 #

• 排查HAProxy与Jetty集群的网络：
  • 在HAProxy服务器上用mtr测试到各Jetty节点的网络路径，查看是否存在丢包、高延迟节点
  • 用tcpdump抓取HAProxy到Jetty的TCP握手包，计算SYN到ACK的时间差，确认是否存在TCP连接建立缓慢的问题
  • 检查Jetty节点的内核监听队列：执行netstat -s | grep "listen queue overflows"，若数值持续增长，说明Jetty的监听队列已满，新连接会被内核阻塞，这部分等待时间会被HAProxy统计，但Jetty的New Relic不会记录
• 排查客户端到HAProxy的网络：若客户端与HAProxy之间存在网络波动（如丢包、高延迟），HAProxy统计的总时间会被拉长，但Jetty的处理时间不受影响

3. 连接复用与TCP参数配置 #

• 检查HAProxy连接复用：确认是否启用option http-keep-alive，若未启用，HAProxy会为每个请求新建TCP连接，连接建立的耗时会被计入总响应时间
• 优化Jetty与内核TCP参数：调整Jetty的acceptors、selectors配置，同时检查内核的tcp_max_syn_backlog、somaxconn参数，避免因连接队列不足导致的等待
• 验证EJB远程连接池：检查Web API到Wildfly的EJB连接池配置，若连接数不足，Jetty线程会等待获取EJB连接，这部分等待时间可能未被New Relic完整统计，可查看New Relic的EJB调用链路细节确认

4. 统计口径的细节偏差 #

• 确认New Relic统计范围：查看Jetty上New Relic的事务追踪，确认是否包含了线程等待时间（如等待EJB连接、数据库连接），部分情况下New Relic可能只统计CPU处理时间，遗漏等待阶段
• 检查HAProxy计时起点：若客户端发送大请求时采用分段传输，HAProxy会从接收到第一个字节开始计时，而Jetty的New Relic是从接收到完整请求开始计时，这部分客户端发送数据的时间会导致两者统计差异

5. 负载均衡策略的隐性问题 #

• 排查节点网络性能：当前使用轮询策略，可能存在部分Jetty节点网卡故障或带宽不足，导致数据传输缓慢，但CPU负载仍处于低位，这类节点会拉低HAProxy的平均响应时间
• 优化健康检查配置：确认HAProxy健康检查的inter（检查间隔）、fall（失败判定次数）是否合理，若健康检查不及时，可能会将网络异常的Jetty节点仍纳入负载均衡，导致请求被分发到慢节点

快速验证步骤 #

1. 先查看HAProxy的实时统计和日志，定位差异是来自队列等待、网络延迟还是后端处理
2. 在Jetty节点上用tcpdump抓取HAProxy请求，对比请求到达Jetty的时间与HAProxy记录的请求开始时间，计算网络传输耗时
3. 查看New Relic的事务详情，确认Jetty处理时间是否覆盖了反序列化、EJB调用、序列化全环节
4. 临时将HAProxy负载均衡策略改为leastconn，验证是否因节点网络负载不均导致差异

内容的提问来源于stack exchange，提问作者Mile Zajkovski