Flomesh Service Mesh(FSM)旨在提供服务网格功能、注重高性能和低资源消耗。这使得资源受限的边缘环境能够利用类似云的服务网格功能。

在本次测试中,我们对 FSM(v1.1.4)Istio(v1.19.3) 进行了基准测试。主要关注在使用两种不同网格时的服务延迟分布,以及数据平面的资源开销。

FSM 使用 Pipy 作为数据平面,而 Istio 则使用 Envoy

测试前,重要的是要注意,我们的重点是比较它们之间的延迟和资源消耗,而不是极限性能。

测试环境

基准测试在运行于 Azure Cloud VM 的 Kubernetes 集群中进行。该集群包括 2 个Standard_D8_v3节点。FSM 和 Istio 均配置为宽松流量模式和 mTLS,其他设置均为默认

  • Kubernetes:K3s v1.24.17+k3s1
  • 操作系统:Ubuntu 20.04
  • 节点:8 核 32G 内存 * 2
  • Sidecar:1 核 512Mi 内存

测试工具位于 此仓库fsm 分支,该仓库从 istio/tools 分叉而来。

测试流程

测试流程记录在 此文件 中。

测试工具中有两个应用程序:fortioclient 和 fortioserver。负载是由 kubectl exec 触发 fortioclient 生成的。

对于两个网格,都进行了基线(无 sidecar)和双边车(两个 sidecar)模式的测试。负载生成设置为在 QPS 1000 下的 2、4、8、16、32、64 并发。您可以查看 FSMIstio 的基准配置。

还有一个重要方面是将 请求和限制资源 设置为 1000m512Mi

延迟

图示:xxx_baseline 表示服务直接访问,不通过 sidecar;xxx_both 表示客户端和服务端都有 sidecar。

X 轴表示并发数;Y 轴表示延迟,单位是毫秒,数值越小越好。

P50

P90

P99

P999

资源消耗

在 CPU 和内存占用图中,X 轴表示并发数;CPU 图的 Y 轴单位毫秒数,内存图的 Y 轴为 Mi,二者都是越低越好。

客户端 sidecar CPU

服务器端 sidecar CPU

客户端 sidecar 内存

服务器端 sidecar 内存

总结

此次,我们对 FSM 和 Istio 数据平面在限制 sidecar 资源下进行了基准测试。

  • 延迟:FSM 的 Pipy sidecar 代理的延迟低于 Istio 的 Envoy,特别是在高并发情况下。
  • 资源消耗:仅有 2 个服务时,FSM 的 Pipy 比 Istio 的 Envoy 消耗更少的资源。

从结果来看,FSM 能够在低资源使用下仍保持高性能,更有效地利用资源。因此,FSM 特别适用于资源受限和大规模场景,有效降低成本。这些优势得益于 Pipy 的低资源消耗、高性能特性。

当然,FSM 除了适用于云计算场景,也适用于边缘计算场景。


Flomesh
1 声望0 粉丝