eCapture1.52版本是否进行过基础的性能和压力测试？

[fengzhibo294]

运行环境：

• 操作系统：openEuler 22.03 (LTS-SP3) x86_64
• 硬件：虚拟机，Intel Xeon E5-2620 v4 2.10GHz，16 核
• eCapture：1.52 版本（Ubuntu 环境自行编译）
• OpenSSL：1.1.1w（2023-11-16）、 nginx/1.21.5

程序修改与运行配置：
1、eBPF Map 大小 const MapSize int = 1024 * 8
2、关闭核心逻辑：注释 m.processor.Write(eventStruct)，不做 HTTPS 明文解析，仅保留基础连接 / 事件识别
具体操作是在dumpSslData函数注释掉//m.processor.Write(eventStruct)
3、新增日志：
AddConn 函数打印新连接建立日志
dumpSslData 函数打印 SSL 数据事件日志（UUID 去重，仅首次打印）
4、去重机制(m *MOpenSSLProbe) dumpSslData中

			connInfo := m.GetConn(eventStruct.Pid, eventStruct.Fd)
			if connInfo == nil {
				...
			}else {
				...
				
				//添加的代码 uuidQueue原型声明var uuidQueue map[string]bool
				uuid := eventStruct.GetUUID()
				if !uuidQueue[uuid] {
					uuidQueue[uuid] = true
					m.logger.Debug().Str("dumpSslData uuid", uuid).Msg("")
				}
			}

	5、日志输出：全部重定向到 log.log

测试用例：
curl 批量发送 HTTPS 请求，请求参数：HTTP/1.1、关闭长连接（no-keepalive）、上传 96KB 文件。
测试指令：for i in {1..160}; do curl -k -s --http1.1 --no-keepalive -o /dev/null -w "第${i}次：%{http_code}\n" -F "file=@/root/ssl_test/test.txt" https://172.20.64.81/upload; sleep 0.01; done
间隔：0.01s / 0.1s / 0.5s / 1s 均测试过

测试结果：
AddConn 日志 稳定 160 条（连接建立无丢失）
dumpSslData 日志 不稳定：
偶尔 320 条（正常）
绝大多数情况 <320 条（固定丢失事件）
降低请求频率（0.1s~1s）依然丢失
手动测试一条接一条测试测试正常，间隔2-3秒curl -k -F "file=@/root/ssl_test/test.txt" https://172.20.64.81/upload

核心结论：
请问下eCapture 1.5.2 官方做过基础性能 / 压力测试？

麻烦帮忙看下，谢谢！@cfc4n @yuweizzz

[yuweizzz]

不太确定，但应该是存在丢失情况的，可以参考以前的 issue

[zenyanle]

之前是有迁移到Ringbuf来减少丢包的打算，但是目前倾向于TC+密钥捕获方案

[dosubot]

@fengzhibo294 感谢你详细的测试报告。你发现的事件丢失问题是已知的架构层面的限制，此前也有其他用户在高吞吐场景下报告过类似的问题。

关于性能/压力测试： 项目中有一份性能测试方法论文档 [1]，描述了使用 wrk 等工具的基准测试方法，但目前没有自动化的性能回归测试，性能基准测试被列为未来工作 [2]。

关于你遇到的事件丢失根因： eCapture 的事件从内核传递到用户空间经过多个缓冲层（perf buffer → Go channel → 输出写入），每一层都可能发生静默丢弃（silent drop），且没有反压（backpressure）机制 [3]。具体来说：

1. Perf buffer 溢出 — 当 SSL 事件速率超过用户空间的消费速度时，perf buffer 会溢出。丢失事件会被检测到（record.LostSamples），但仅记录日志、不会重试 [3]。
2. 多层级级联丢弃 — 此前有用户报告即使将 buffer 增大到 32GB 仍然有约 75% 的丢包率，且与 buffer 大小无关 [4]。
3. 单线程顺序处理 — 用户空间的事件解码和分发是串行的，慢的 handler 会阻塞后续事件处理 [5]。

建议的解决方法： 项目维护者此前针对高吞吐场景推荐的方案是使用 keylog 模式 + 外部 tcpdump 来捕获流量，而不是使用 text 模式或 pcapng 模式的原生解析 [4] [6]。你可以通过添加 --debug 和 --logaddr 标志来观察是否有 perf buffer 丢失的警告日志。

另外，你提到修改了 MapSize 为 1024 * 8，这对应的是 eBPF map 的大小。实际控制 perf buffer 大小的是 --mapsize CLI 参数（默认 8MB/CPU）[7]，增大这个值可能有一定帮助，但根据已有反馈，在高频场景下并不能完全解决丢失问题。

Written by @dosu, approved by cfc4n

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.