Kubernetes 下 web 服务的性能测试三部曲之三:横向扩容
欢迎访问我的 GitHub
这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos
本篇概览
本章是《Kubernetes 下 web 服务的性能测试三部曲》系列的终篇,之前我们用 AB 和 JMeter 两种工具压测了 k8s 环境下的 Tomcat,并通过调整内存和 CPU 来验证纵向扩容的效果,本章我们来验证横向扩容对吞吐量的影响;
前文列表
《Kubernetes 下 web 服务的性能测试三部曲》的前两篇文章请点击以下链接:
基本环境信息
基本环境的配置,与第一章一致,Tomcat 的 deployment 配置如下:
注意,本章实战的 Pod 内存为 512M,因为 256M 的 Pod 吞吐率太低,从启动到预热(用来应对 JIT 的第一次测试,丢弃成绩),都会耗费大量时间,因此用 512M 可以节省测试时间;
请按照上述配置将 deployment 和 service 在 k8s 环境启动起来,启动命令如下,在 tomcat.yaml 文件所在目录下:
横向扩容,将 Pod 数从 1 增加到 8
将 Pod 数从 1 增加到 8,执行以下命令即可:
因为新的 Pod 创建、启动、初始化等操做,需要等待几分钟再进行测试;
继续继续 AB 和 JMeter 测试,然后再分别将 replicas 参数设置为 4、2、1,得到结果如下表所示:
以上的结果可以发现,随着 Pod 数的翻倍,吞吐量也是在线性增长的,增长的效果接近翻倍,也就是说横向扩容并没有出现纵向扩容时的那种单机极限的瓶颈,在节点数量得以保证的情况下,可以通过横向扩容来提升吞吐量(因为硬件资源的限制,我这里只能将 Pod 扩展到 8 个,如果您有条件可以继续测试下去);
节省测试时间的方法
正常的测试顺序是副本数从 1 到 2,然后从 2 到 4,再从 4 到 8,这样每次扩容后都会有容器创建,都要等待 Pod 创建和初始化,然后还要预热(避免 JIT 的影响),所以,本次实战我的顺序是一开始直接扩容到 8 个 Pod,然后等待创建和初始化,再正常预热,用 AB 和 JMeter 测试 Pod 等于 8 的吞吐量,然后将 Pod 数从 8 缩减到 4,缩减后剩下的 4 个 Pod 都是缩减之前用过的,不需要再预热就能直接压测了,这样从 8 到 4,从 4 到 2,从 2 到 1 的几次缩减都不需要等待初始化和执行预热了;
和上一章的数据差异
细心的读者会发现,本章在 Pod 内存为 512M 的时候,吞吐量的数字和上一章是不同的,因为本章使用的硬件资源和上一章有所不同所致,但是实战的软件环境、步骤和镜像都是完全相同的;
至此,《Kubernetes 下 web 服务的性能测试三部曲》就全部结束了,希望能对你您在 K8S 环境下的扩容和压测都有所帮助,也欢迎您的关注和来信探讨:zq2599@gmail.com
欢迎关注 InfoQ:程序员欣宸
版权声明: 本文为 InfoQ 作者【程序员欣宸】的原创文章。
原文链接:【http://xie.infoq.cn/article/bb415c3cb759c326b1213c8ed】。文章转载请联系作者。
评论