Linkerd基准测试

作者：William Morgan

更新5/30/2019：根据Istio团队的反馈，Kinvolk重新运行了一些Istio基准。结果在很大程度上与之前相似，Linkerd在延迟、内存占用（可能还有CPU）方面保持着明显优于Istio的优势。下面可以注意到Istio的更新数字。

https://github.com/kinvolk/service-mesh-benchmark/issues/5#issuecomment-496482381

Linkerd的目标是成为世界上最快、最轻、最简单的服务网格。为此，几个星期前，我们请Kinvolk 善良的员工执行一个独立的基准测试。我们希望由具有强大系统专业知识和基准测试历史的第三方进行公正的评估。Kinvolk符合这个描述，他们同意接受挑战。

我们问Kinvolk几件事：

• 度量尾部延迟、CPU使用和内存消耗的基准 — 我们认为这三个指标最能反映服务网格的运行成本。
• 与根本不使用服务网格的基线进行比较。
• 与Istio，另一个服务网格，的比较。（我们经常被问到这两者的比较。）
• 为应用程序“at load”和“at scale”设置的实际测试设置，包括特性之间的苹果对苹果比较，以及对方差和测量误差的控制。
• 用于复制这些测试的可下载框架，以便任何人都可以验证他们的工作。

今天，Kinvolk发表了他们的研究结果。你可以在这里看到完整的报告：Kubernetes服务网格基准测试。Kinvolk测量了Linkerd 2.3 edge-19.5.2和Istio 1.1.6，这是测试时可用的最新版本。他们测量了两种情况下的性能：“500rps”和“600rps”，有效地表示测试装置的“高”和“非常高”负载。

https://kinvolk.io/blog/2019/05/kubernetes-service-mesh-benchmarking/

下面是他们研究结果的摘要。（注意，对于Istio，Kinvolk测试了两种配置，“stock”和“tuned”。我们只关注下面的“tuned”配置。）

延迟

500rps延时图

600rps延时图

延迟可以说是服务网格中最重要的数字，因为它度量了服务网格对用户（而不是操作人员）的影响。延迟也是最难推理的，因为它最好作为一个分布来度量。

Kinvolk从负载生成器的角度测量延迟，这意味着这些延迟数字是他们测试的应用程序的函数 — 如果调用图更深，我们将看到额外的延迟，如果它更浅，这些数字将更少。因此，原始数据没有比较重要 — Linkerd与基线和Istio的比较如何？

在500rps条件下，Linkerd的p99延迟为6.7ms，比无服务网格3.1ms的基线p99延迟多3.6ms。（换句话说，99%的情况下，没有服务网格的请求花费不到3.1ms，而99%的情况下，使用Linkerd的请求花费不到6.7ms。）在p999水平（99.9%的百分位），Linkerd的延迟明显更差，为675ms，比对基线的p999的4ms。在Linkerd的整个测试中，最坏的响应时间是1.8s的延迟，而基线的最坏情况是972ms。

相比之下，在500rps的情况下，Istio的p99延迟为643ms，几乎比Linkerd的p99慢100倍。与Linkerd的679ms相比，它的p999要超过1秒，最糟糕的情况是整整5秒的延迟，是Linkerd的2.5倍。

（更新：Kinvolk重新调优的Istio基准将Istio的p99从Linkerd的100倍降低到26x和59x。它还将Istio的p999降到不到一秒，不过仍然是Linkerd的两倍。）

在600rps条件下，两个服务网格之间的差异被夸大了。Linkerd的p99从6.7ms提升到7ms，超过了“无服务网格”基线的4ms，而Istio的p99整整4.4分钟（！）。Linkerd的p999上升到850毫秒，而基线是3.8毫秒，Istio的p999几乎是6分钟。Istio的p50（中值）延迟也是不可接受的17.6秒。简而言之，在Kinvolk的600rps条件下，Istio不能有效地执行。

（更新：Kinvolk重新调优的Istio基准测试在600rps条件下显示了类似的性能，Istio的p99延迟为分钟，中值延迟为10到20秒。）

概要：Linkerd比Istio在延迟方面具有优势。在500rps条件下，Istio的p99是Linkerd的100倍。在600rps条件下，Istio的延迟始终是不可接受的。然而，与500rps条件下的基线相比，这两种网格都在99.9%的百分比处引入了显著的延迟。

内存消耗

500rps内存图

600rps内存图

在500rps时，Linkerd在所有数据平面代理上的内存使用量为517mb（平均每个代理5.7mb），而控制平面本身的内存使用量略低于500mb，内存总量约为1gb。相比之下，Istio在所有数据平面代理上的内存使用量为4307mb（平均每个代理为47mb），在控制平面上的内存使用量为1305mb，总计将近5.5gb。

在600rps条件下，情况几乎相同。当然，与0mb的基线使用相比，这两个网格都受到了很大的影响！

（顺便提一下，Linkerd在这些运行中控制平面内存使用量的25%是它的Prometheus实例，它临时将聚合的度量结果存储到Linkerd的仪表板和CLI中。可以说，这应该被排除在外，因为Prometheus在Istio中被禁用。）

概要：Linkerd有明显的内存优势。Istio消耗的内存是Linkerd的5.5倍。特别是Linkerd的数据平面，消耗的内存还不到Istio的八分之一。

CPU消耗

500rps cpu图

600rps cpu图

当测量CPU消耗时，这两种方法得到了相似的结果。在500rps运行中，Linkerd的数据平面代理累计占用1618mc （millicore），其控制平面占用82mc，共计1700mc。Istio的数据平面代理消耗1723mc，控制平面消耗379mc，共消耗2100mc，比Linkerd增加23%。然而，在600rps的运行中，结果发生了逆转，Linkerd使用的是1951mc，而Istio使用的是1985mc。在这次运行中，Linkerd的数据平面在600RPS条件下消耗的CPU比Istio多15%。（尽管应该指出的是，由于Istio不能实际返回600rps，所以它与Linkerd的比较并不完全公平。）

概要：CPU使用情况类似于Linkerd和Istio。在600rps条件下，Linkerd的数据平面CPU利用率高于Istio，尽管很难知道这个结果的真实性，因为在这种情况下Istio不能完全执行。

（更新：Kinvolk重新调优的Istio基准测试显示“Istio代理sidecar的CPU使用率大幅增加”。虽然没有数字报告，但从这个描述可以清楚地看出，在这个配置中，Linkerd的CPU使用量小于Istio。）

结论

总的来说，我们对Linkerd在这个测试中的性能很满意，我们也很高兴能够对引入服务网格的相对成本进行全面的量化，并为运行这些基准测试提供一个公开的、可重复使用的工具。

https://github.com/kinvolk/service-mesh-benchmark

我们很高兴地看到Linkerd在延迟和内存消耗方面比Istio具有非常显著的优势。虽然CPU使用情况相当，但我们认为Linkerd可以做得更好。我们怀疑在linkerd-proxy中有一些容易实现的功能，我们急切地想看看在接下来的几个版本中，一些概要分析和调优是否可以减少CPU消耗。（我们希望得到你的帮助 — 加入我们的Slack，或者下周到KubeCon EU来和我们谈谈！）

https://linkerd.io/2019/05/18/linkerd-benchmarks/slack.linkerd.io

https://buoyant.io/2019/04/23/linkerd-community-guide-to-kubecon-eu-2019/#_ga=2.236775041.1026167182.1558316397-1296284285.1554340738

在未来，我们希望像Meshery这样的项目能够为此类基准提供一个行业标准方法。它们对用户和项目都有好处。

https://layer5.io/meshery/

Kinvolk测试的彻底性给我们留下了深刻的印象，我们要感谢他们做出了这么大的努力。完整的报告详细描述了他们在构建准确的测试条件、减少可变性和生成有统计意义的结果方面所投入的难以置信的努力。绝对值得一读！

https://kinvolk.io/blog/2019/05/kubernetes-service-mesh-benchmarking/

最后，我们还要感谢Packet的那些好心的人，他们允许Kinvolk使用CNCF社区集群来执行这些实验。Linkerd社区欠你一份感激之情。

https://www.packet.com/

https://github.com/cncf/cluster

Linkerd是一个社区项目，由CNCF托管。如果你有功能需求、问题或评论，我们欢迎你加入我们快速增长的社区！Linkerd托管在GitHub上，我们在Slack、Twitter和邮件列表上都有一个蓬勃发展的社区。来一起玩吧！