必须将apache负载均衡器纳入基准测试路径，测试地址应为lb入口（如http://lb.example.com/），通过ab/wrk对比直连后端与经lb的响应时间，监控mod_status和balancer-manager验证分发均匀性及健康状态。

直接对后端服务做基准测试时，如果中间隔着 Apache 负载均衡器，就不能只测单台后端——必须把负载均衡器本身也纳入测试路径，否则结果无法反映真实链路性能。关键在于：测的是“用户请求经过 LB 到后端再返回”的端到端表现，而不是后端裸机能力。

明确测试目标与路径

先确认你要验证什么：

• 是看 LB 是否引入明显延迟（比如比直连后端多出 5ms+）
• 还是测整条链路在并发下的吞吐、错误率、响应时间分布
• 或是验证 LB 的分发是否均匀（比如 2 台后端实际接收请求数偏差是否超 10%）

测试地址必须是负载均衡器的入口地址（如 http://lb.example.com/），不是后端服务器 IP。所有压测工具都应指向这个 VIP 或域名。

启用并监控 LB 状态页

在 Apache 负载均衡器上启用 mod_status 并开启 ExtendedStatus On，同时确保 mod_proxy_balancer 的状态页面可用（通常为 /balancer-manager）。测试中实时访问这两个页面，可观察：

Apache Superset Dashboard and SQL Exploration Skill

Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

下载

• 各 BalancerMember 的当前活动连接数、已处理请求数、失败次数
• LB 自身的 CPU、空闲工作进程、每秒请求数（由 mod_status 提供）
• 是否存在某后端持续 marked down 或响应超时（说明健康检查异常）

用 ab 或 wrk 做轻量级端到端基准

推荐从简单工具起步，快速建立基线：

• ab 示例：`ab -n 5000 -c 200 -k http://lb.example.com/api/health`（启用 Keep-Alive，避免连接开销干扰）
• wrk 示例：`wrk -t 8 -c 400 -d 60s --latency http://lb.example.com/`（输出详细延迟分布）

重点对比两组数据：
— 直连某台后端（如 http://backend1:8080/）的 ab 结果
— 经过 LB（http://lb.example.com/）的 ab 结果
若 LB 层平均响应时间增加超过 10%，需检查 Proxy 配置（如是否启用了冗余 DNS 解析、SSL 会话复用是否生效）。

验证分发策略与后端负载均衡性

仅看总吞吐不够，要确认流量确实按预期分配：

• 在每台后端服务器上开启访问日志，并添加 %{BALANCER_NAME}e 或自定义 header 记录被哪个 LB 实例转发（需在 ProxyPass 中加 env=LB_NAME）
• 用 wrk 或 JMeter 发起 1000+ 请求后，统计各后端 access.log 中来源 IP（或自定义字段）出现频次
• 轮询模式下，两台后端请求计数偏差应 ≤ ±5%；加权模式下，应与 loadfactor 设置比例基本一致（如 3:1 → 实际 75% : 25%）

若偏差过大，检查是否启用了 sticky session（如 route=xxx）、后端健康检查误判，或存在连接复用导致长连接未重均衡。