keveinliu
作者keveinliu·2021-11-01 11:30
CTO·Flomesh

性能对比——Istio数据平面性能测试

字数 2934阅读 2904评论 0赞 0

# 性能对比——Istio数据平面性能测试

上一次做了 Flomesh 的性能测试 ,可能会有人关注与其他服务网格的对比。这次我们以同样的方式对 Istio 进行了测试。

本次使用的脚本已提交到 https://github.com/flomesh-io/toolsistio 分支。

## 测试目标

  • 为服务增加一个 Istio inbound sidecar,测试服务经过其代理后对性能的影响。
  • 测试对象是一个服务,一个 Pod 实例。
  • 客户端固定 1000 QPS 的条件下( 服务端实际 QPS 不一定真正能达到 1000 QPS ),并发连接数分别为 2、4、8、16、32、64 对服务进行 180 秒 的持续测试,每轮测试后暂停 30s
  • 重点关注 CPU、MEM、p50、p90 以及 p99 的数据。

## 测试方案

  • 还是采用与上次测试一样,同样也是 Istio 官方使用的工具 Fortio ,版本为 1.17.0
  • Istio 使用的最新的 1.11.3 ,安装的 default profile分别使用 Istio 官方默认配置和部分优化后的配置进行测试(优化项见下文)如果有感兴趣小伙伴,欢迎一同优化和测试。
  • 使用 k3s v1.19.13+k3s1
  • 测试将在 阿里云 上进行,共需要 3 台 ECS,操作系统 Ubuntu 20.04 ,地域美国弗吉尼亚,可用区 B

| 序号 | 型号 | 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 服务分别监听在 80808077 端口。(参考了 Istio 的测试,由于 iptables 的流量拦截方式,不能访问被代理服务的原生端口)
  • 通过 NodePort 暴露服务,分别在 3099030980
  • 部署 samples/addons/prometheus.yaml 做指标的采集。
  • fortio 的客户端执行脚本,分别测试经过sidecar访问服务和直接访问服务两种情况,并将测试结果保存为JSON。
  • 在测试完成之后,会根据上一步保存的 JSON 中的每个测试用例的开始及结束时间,通过 Prometheus API (通过 NodePort 暴露访问)查询对应时段内的 CPU 和内存使用情况并汇总。
  • 最后,使用汇总数据生成结果报告及折线图。

## TL;DR - 结论

  • Istio 的 sidecar 在 CPU 的占用上非常明显。
  • 开启或不开启 Jitter,Istio sidecar 都会增加约 900m 的 CPU,增加 0.1MB 的内存。
  • 调优之后(优化项见下文),通过 sidecar 访问的延迟减少。比如 P99 的延迟,优化前延迟 25+ms ,优化后 7+ms ,提升显著。而不使用 sidecar 的请求延迟在 2ms 左右。​
  • 客户端连接数足以达到期望 QPS 时,请求通过 sidecar 的测试并未达到期望的 QPS。

 2021-10-13-16-07-49

2021-10-13-16-07-49

## 性能测试

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

 latency-p50-jitter-false

latency-p50-jitter-false

P90

 latency-p90-jitter-false

latency-p90-jitter-false

P99

 latency-p99-jitter-false

latency-p99-jitter-false

随着连接数的增加,通过 sidecar 请求的延迟相比直接访问的增加比较明显,且对 P50、P90、P99 上的影响基本一致。

CPU

 cpu-server-jitter-false

cpu-server-jitter-false

在 CPU 占用方面,通过对比,可以看出在连接数为 2、4 的时候 CPU 的占用就很高了;在连接数达到 8 之后就达到了最高。

MEM

 mem-server-jitter-false

mem-server-jitter-false

内存方面,在集群只有一个服务的情况下,使用 sidecar 与不使用 sidecar 对内存的影响不大,基本都在 48M 左右。

### 开启 Jitter

P50

 latency-p50-jitter-true

latency-p50-jitter-true

P90

 latency-p90-jitter-true

latency-p90-jitter-true

P99

 latency-p99-jitter-true

latency-p99-jitter-true

CPU

 cpu-server-jitter-true

cpu-server-jitter-true

MEM

 mem-server-jitter-true

mem-server-jitter-true

### 调优之后

#### 不开启 Jitter

P50

 latency-p50-jitter-false

latency-p50-jitter-false

P90

 latency-p90-jitter-false

latency-p90-jitter-false

P99

 latency-p99-jitter-false

latency-p99-jitter-false

CPU

 cpu-server-jitter-false

cpu-server-jitter-false

MEM

 mem-server-jitter-false

mem-server-jitter-false

#### 开启 Jitter

P50

 latency-p50-jitter-true

latency-p50-jitter-true

P90

 latency-p90-jitter-true

latency-p90-jitter-true

P99

 latency-p99-jitter-true

latency-p99-jitter-true

CPU

 cpu-server-jitter-true

cpu-server-jitter-true

MEM

 mem-server-jitter-true

mem-server-jitter-true

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广