上一章 Kubernetes 下 web 服务的性能测试三部曲之一: 准备工作我们将 web 服务搭建好, 再用 AB 和 JMeter 测试了单个 Pod 的性能, 今天我们来测试一下纵向扩容对服务能力的提升;
实战步骤
今天的实战用以下几种方式提升单个 Pod 性能:
1. 内存资源从 256M 提升到 512M;
2. 内存资源从 512M 提升到 1G;
3. 内存资源从 1G 提升到 2G;
4. CPU 资源从 0.1 提升到 1;
5. CPU 资源从 1 提升到 2;
注意: 每次纵向扩容之前, 需要停止和删除原有的 deployment 和 service, 扩容后, 第一次测试的成绩请丢弃, 因为 JIT 在理论上对结果有影响;
如何停止和删除原有的 deployment 和 service
执行以下命令即可先删除 service, 再删除 deployment:
kubectl delete service tomcathost && kubectl delete deployment tomcathost
内存资源从 256M 提升到 512M
打开上一章我们搭建 web 服务时创建的 tomcat.yaml 文件, 内容如下:
- apiVersion: extensions/v1beta1
- kind: Deployment
- metadata:
- name: tomcathost
- spec:
- replicas: 1
- template:
- metadata:
- labels:
- name: tomcathost
- spec:
- containers:
- - name: tomcathost
- image: bolingcavalry/k8stomcatdemo:0.0.5
- tty: true
- ports:
- - containerPort: 8080
- resources:
- requests:
- memory: "256Mi"
- cpu: "100m"
- limits:
- memory: "256Mi"
- cpu: "100m"
如上所示, 找到 resources 节点下的两个 memory 节点, 将值从 256Mi 改成 512Mi;
执行 AB 测试:
ab -n 20000 -c 100 http://192.168.119.153:30008/getserverinfo
得到的结果如下:
- Concurrency Level: 100
- Time taken for tests: 68.527 seconds
- Complete requests: 20000
- Failed requests: 0
- Total transferred: 3700000 bytes
- html transferred: 1040000 bytes
- Requests per second: 291.86 [#/sec] (mean)
- Time per request: 342.635 [ms] (mean)
- Time per request: 3.426 [ms] (mean, across all concurrent requests)
- Transfer rate: 52.73 [Kbytes/sec] received
接下来用 JMeter 压测, 得到结果如下:
Samples | Average | Median | 90% Line | 95% Line | 99% Line | Min | Max | Error % | Throughput | Received KB/sec | Sent KB/sec |
---|---|---|---|---|---|---|---|---|---|---|---|
20000 | 489 | 294 | 1100 | 1608 | 3696 | 0 | 10899 | 0.00% | 188.8/sec | 30.61 | 25.45 |
如上所示, 内存翻倍后对吞吐量的提升非常明显;
继续提升内存
继续修改 tomcat.yaml 的内存参数, 记录下来每次 AB 和 JMeter 的测试结果, 这里就不赘述了, 稍后在表格中统一给出;
升级 CPU
继续修改 tomcat.yaml, 将内存恢复为 256Mi, 将 CPU 从 100m 改成 1000m, 也就是从 0.1CPU 改为 1CPU, 然后再从 1CPU 改为 2CPU, 分别记录下来每次 AB 和 JMeter 的测试结果;
小结纵向扩容
下面的表格将前面每次修改后的测试结果列举出来了:
内存 | CPU | 吞吐率(AB) | 吞吐率(JMeter) |
---|---|---|---|
256M | 0.1 | 33.77 | 31.21 |
512M | 0.1 | 291.86 | 188.80 |
1G | 0.1 | 326.19 | 324.58 |
2G | 0.1 | 340.61 | 340.10 |
256M | 1 | 81.36 | 80.61 |
256M | 2 | 86.62 | 82.11 |
从上述数据可以看出:
1. 内存扩容在 1G 之前是有显著提升的, 但过了 1G 提升就不明显了;
2. CPU 资源增大到原有的 10 倍后, 吞吐量有 3 倍左右提升, 继续加倍 CPU 资源, 也无法带来明显提升;
这里要注意的是此次测试的后台代码很简单, 并未涉及 RPC 数据库缓存等, 数值不能作为生产环境的参考, 因为每个实际的业务都有其自身的特征, 此处仅提出一种扩容和验证扩容效果的手段;
至此, 纵向扩容的测试就完成了, 接下来的章节, 咱们一起测试一下横向扩容的效果;
来源: http://blog.csdn.net/boling_cavalry/article/details/79327660