istio 相关文章列表：

• istio 简介
• istio 性能测试

官方性能测试

在官方给定的标准测试下（1000 services、2000 sidecars、70,000/s 网格内调用），大概性能数据如下：

1. Envoy 代理每 1000 qps 消耗 0.6 vCPU 和 50 MB 内存；
2. 遥测服务每 1000 qps （网格内调用）消耗 0.6 vCPU；
3. Pilot 消耗 1 vCPU 和 1.5 GB 内存；
4. Envoy 代理使得 90% 的调用都增加 8ms 的延迟（有 server 端代理和 client 端代理，代理流量进出），如果只代理入流量，那么 P90 增加 2ms；

有几点需要注意一下：

1. proxy 的策略越复杂，延时增加越多；
2. 遥测数据异步发送，不影响当前请求的响应时间，但是会造成网络拥堵，间接增加延时；

测试方案说明

本次测试基于 istio 1.2 版本，单机版 k8s（v1.14.3）。

如果嫌数据说明太长的同学，可以直接跳到总结一节。

测试场景示意图

1. fortio 是一个端到端负载测试工具，在本例中调用 Service A；
2. Service A 与 Service B 之间有调用关系，可以控制他们的调用深度（即 Service A 返回给 fortio 之前经过 几次 A 和 B 之间调用）；
3. fortio 与两个 Service 在同一 namespace 下；

测试结果

1. istio 性能损耗

在 500 QPS、调用深度为 3（即 Service A 返回给 fortio 之前经过 3 次 A 和 B 之间调用）的情况下，有 istio 代理和没有 istio 代理的性能差异：

500qps_deep3_直方图

500qps_deep3_调用延迟

可以看到，istio 的 P90 = 6.63 ms（90% 的调用都小于 6.63 ms），没有 istio 的 P90 = 3.70 ms 。调用延时增加了 3ms。

2. 调用深度对延迟的影响

在 500 QPS、调用深度分别为 0、3、5、8、10、12 的情况下，有 istio 代理的调用延迟分析图：

with_istio_legency

无 istio 代理的调用延迟分析图：

no_istio_legency.png

选取调用深度分别为 5、8、10、12的测试，进行对比:

legency_对比.png

红线左侧是深度分别为 5、8、10、12 时有 istio 代理的调用延迟，红线右侧是深度分别为 5、8、10、12 时无 istio 代理的调用延迟。

可以看到随着调用深度的增加，istio 代理所增加的延时相应增加，但增加幅度放缓。8 次以上的调用深度，有 istio 代理的 P90 平均比无 istio 代理的 P90 高 10 ms。

3. QPS 对延迟的影响

在调用深度为 3、QPS 分别为 300、 500、 1000 的情况下，有 istio 代理的调用延迟分析图：

qps_with_istio_legency.png

无 istio 代理的调用延迟分析图：

qps_no_istio_legency.png

可以看到，QPS 的增加并不会增加调用延时。

总结

1. 我们得到的测试结果基本符合官方给出的结论。
2. 调用延时的增加主要和调用深度（经过 istio proxy 的层数）正相关；
3. 调用层数每增加一层，有 istio 的 P90 延时比无 istio 的 P90 延时平均增加 1 ms；
4. QPS 的增加并不会增加调用延时；我们得到的测试结果基本符合官方给出的测试。

备注：我在测试时，服务间调用 QPS 最高压到过 45k，以上结论仍然成立。对于 istio proxy （envoy）的性能瓶颈在哪里，需要后面做出更详细的测试。