# 性能对比——Istio数据平面性能测试
上一次做了 Flomesh 的性能测试 ,可能会有人关注与其他服务网格的对比。这次我们以同样的方式对 Istio 进行了测试。
本次使用的脚本已提交到 https://github.com/flomesh-io/tools
的 istio
分支。
## 测试目标
## 测试方案
1.11.3
,安装的 default profile 。 分别使用 Istio 官方默认配置和部分优化后的配置进行测试(优化项见下文) 。 如果有感兴趣小伙伴,欢迎一同优化和测试。| 序号 | 型号 | CPU | 内存 | 角色 |
| 1 | ecs.c6.large | 2 vCPU | 4G | master |
| 2 | ecs.g6.xlarge | 4 vCPU | 16G | node |
| 3 | ecs.c6.xlarge | 4 vCPU | 8G | fortio client |
环境的搭建请参考 Flomesh 性能测试环境搭建
## 测试架构
fort
容器(同一个 Pod)作为测试的服务端,原始的 http echo 服务分别监听在 8080
、 8077
端口。(参考了 Istio 的测试,由于 iptables 的流量拦截方式,不能访问被代理服务的原生端口)NodePort
暴露服务,分别在 30990
和 30980
。samples/addons/prometheus.yaml
做指标的采集。NodePort
暴露访问)查询对应时段内的 CPU 和内存使用情况并汇总。## TL;DR - 结论
## 性能测试
Istio 安装的是 default profile
,使用默认设置做了一次测试。同时,按照下面的设置进行了优化后也进行了测试。
apiVersion : install.istio.io/v1alpha1
kind : IstioOperator
metadata :
name : default-mesh-config
spec :
meshConfig :
enableTracing : false #关闭 tracing
enableEnvoyAccessLogService : false #关闭 Evnoy gRPC 访问日志服务
disableEnvoyListenerLog : true #关闭 Envoy 监听器的日志
enablePrometheusMerge : false #禁用 promethues 聚合
defaultConfig :
concurrency : 20 #工作线程数设置为 20,默认为 2
上次测试分别测试开启和关闭 Fortio Jitter 的场景,这次也同样。
### 什么是 Jitter
fortio 提供了一个参数 jitter,用于控制生成高并发测试请求的行为。当设置为 true 时,fortio 会在发送并发请求时,在发送时间上进行一个 +/-10% 范围内的抖动,从而避免惊群效应 ( Thundering Herd Problem )。此次我们分别在开启和关闭 jitter 的情况下进行了测试。
### 调优之前
#### 不开启 Jitter
P50
P90
P99
随着连接数的增加,通过 sidecar 请求的延迟相比直接访问的增加比较明显,且对 P50、P90、P99 上的影响基本一致。
CPU
在 CPU 占用方面,通过对比,可以看出在连接数为 2、4 的时候 CPU 的占用就很高了;在连接数达到 8 之后就达到了最高。
MEM
内存方面,在集群只有一个服务的情况下,使用 sidecar 与不使用 sidecar 对内存的影响不大,基本都在 48M 左右。
### 开启 Jitter
P50
P90
P99
CPU
MEM
### 调优之后
#### 不开启 Jitter
P50
P90
P99
CPU
MEM
#### 开启 Jitter
P50
P90
P99
CPU
MEM
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论