[BUG] deepflow agent对应用性能影响过高

[infra403]

Search before asking

• I had searched in the issues and found no similar feature requirement.

DeepFlow Component

Agent

What you expected to happen

deepflow agent对于业务的tps、rt影响应该在5%以内

How to reproduce

测试环境详细信息，参考：https://github.com/baxiaoshi/deepflow-go-demo

DeepFlow version

v6.3.9

DeepFlow agent list

No response

Kubernetes CNI

calico

Operation-System/Kernel version

Linux release 7.9.2009 (Core)
内核版本: 5.10.109-1

Anything else

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[LYootsz]

你好，请问你的压测工具和deepflow-agent以及redis服务端是否位于同一服务器或节点？

[infra403]

你好，请问你的压测工具和deepflow-agent以及redis服务端是否位于同一服务器或节点？

压测工具是单独的机器，所有的被压测程序、组件都在同一台机器

[LYootsz]

你好，目前确定了该现象的原因

1. 如果 CPU 到顶了，性能影响可能比较大
2. 如果是通过限制了 Thread 数量，CPU 跑不上去，性能影响可能比较大
   推荐在「在给定 TPS 下」测试对 RT 的影响，我们之后会给出这样一个压测工具。

推荐升级到 6.4LTS，deepflow-agent在这个版本性能做了进一步优化，内部测试redis的tps影响降低到了5%。
针对这类应用协议已经开始继续做后续优化。

[infra403]

升级到6.4后，在下面的配置下，对应用的tps影响仍然在5%，如果使用默认配置，则在10%以上，使用helm安装后，默认有那些配置是需要调整的吗？

vtap_group_id: g-f1bdc6a77d
collector_enabled: 0
l4_log_tap_types:
- -1
l7_log_collect_nps_threshold: 20000
l7_metrics_enabled: 0
l7_log_store_tap_types:
- -1
l4_performance_enabled: 0
static_config:
  ebpf:
    disabled: true
    on-cpu-profile:
      disabled: true

[LYootsz]

https://github.com/deepflowio/deepflow-auto-test/tree/main/app-traffic
这是我们用于固定打流的工具，推荐用一下这个看看结果，可以指定固定的tps，以减少由于资源瓶颈带来的数据误差。agent用默认配置就可以，时延影响在5%左右

[LYootsz]

针对redis的复杂查询我们进行了优化，我上面的工具可以设置查询的复杂度，以下是测试结果

[LYootsz]

通过限制线程数来测tps是不严谨的，线程资源会出现瓶颈，如果真的要测agent对redis极限tps的影响应该避开线程达到瓶颈的问题。所以需要放大线程数通过指定极限tps的方法来测试。

[LYootsz]

假设单线程的qps上限只有1w，redis的上限是10w。那这时我们将线程数设置到50并将请求数均匀得分配到每个线程，再打10w的qps，避免由于线程顺序执行达到上限而对测试结果出现影响。

[sharang]

https://github.com/deepflowio/deepflow-auto-test/tree/main/app-traffic 这是我们用于固定打流的工具，推荐用一下这个看看结果，可以指定固定的tps，以减少由于资源瓶颈带来的数据误差。agent用默认配置就可以，时延影响在5%左右

@infra403 看看使用「固定 TPS」的方法来测试，对 CPU 和 RT 的影响如何？

如果无法固定 TPS（你之前使用的方法），我们猜测应该是资源达到了瓶颈。在瓶颈状态下即使不运行 deepflow-agent TPS 也会有较大的波动（有波动实际上就能说明到瓶颈了）。

[sharang]

与 @infra403 沟通后，总结如下。

测试拓扑（所有进程在同一个 k8s node 上）：

client -> http_server -> redis

默认情况下，deepflow-agent 为每个 transaction 采集的 span 如下：

client syscall
client pod nic
http_server pod nic (ingress http)
http_server syscall (ingress http)
http_server syscall (egress redis)
http_server pod nic (egress redis)
redis poc_nic
redis syscall

测试配置	#spans / transaction	TPS
默认配置，全采集	8 (4 cbpf + 4 ebpf)	4950
只采集 eBPF 数据	4 (4 ebpf，使用下面的配置 1)	5150
只采集 Redis eBPF 数据	2 (e ebpf，使用下面的配置 2)	5350
停止 agent，不采集	0	5750

配置1：

tap-interface-regex: some-nic-not-exist

配置2：

tap-interface-regex: some-nic-not-exist
static_config:
  ebpf:
    kprobe-blacklist:
      port-list: $http_port  # 即不采集 HTTP 通信

由于采用的压测程序（上述 client）无法产生固定 TPS 的压力，因此 TPS 会直接和 RT 相关。而由于 eBPF hook 和 cBPF hook 都会或多或少带来一些 RT 上升，因此当 hook 次数越多时累计 RT 影响越大，从而 TPS 影响也会越大。

在 @infra403 的测试中，默认采集了 8 spans / transaction。在 @LYootsz 的测试中，默认采集了 3 spans / transaction（拓扑更简单，client -> redis，三份数据分别是 ebpf syscall + cbpf loopback + ebpf syscall）。因此 @LYootsz 的测试结果对极限 TPS 的影响是 5%，而 @infra403 的测试结果对 TPS 的影响是 10%+。

另外，从上面的数据也能看到，ebpf hook 对 RT 的影响相比 cbpf 更大。我们也会继续看看 ebpf hook 部分是否还有优化空间。实际上 DeepFlow 对 eBPF Hook 的优化非常精细了，比如使用了 batch process、protocol inference acceleration 等机制。

[sharang]

最近奈飞开源了 bpftop https://netflixtechblog.com/announcing-bpftop-streamlining-ebpf-performance-optimization-6a727c1ae2e5

我们打算用这个工具来评估一下 deepflow-agent 中 ebpf 程序的性能是否还有提升空间。