性能测试-关于阿里云PTS使用与思考

1、性能测试必要性

官话：性能测试能帮助用户更好地从技术上来规避系统上线后的风险、评估线上系统的真实能力、根据业务模型摸底线上能力以提前应对

个人理解：服务器有性能瓶颈，用户的操作对于服务器会有影响，但是用户什么操作、多大量的操作，对服务端的内存有影响还是cpu有影响、多大的影响、服务器能否承受，不知道。用户和服务器的关系，其实是灰度的、不可量化的。

而性能测试，可以通过一定的测试策略，在模糊地带找到用户和服务器之间的丝丝关系点，且能量化评估，这是第一点。第二点，性能测试可以来找到整个系统真正的瓶颈（问题点）在哪里，而避免无厘头的扩容来造成成本浪费。

优化一个体系，第一件事一定是提供测试方法和测试指标。

性能测试的效果和具体的测试策略有关，这点我不在本文讨论。本文仅介绍性能测试的整体思路和技术实现

2、性能测试环境选择

测试环境分为生产环境和测试环境

在生产环境测试，精准度较高，参考效果更好，但是需要清理相关的测试数据，且可能会对实际业务造成影响

在测试环境测试，风险可控，难点在于环境的构建和压测的准确性，规模和生产一致的成本也是最高的，所以一般而言有通过等比构建（1/2，1/4，1/8等），甚至是生产环境中部分应用独立部署测试集群，数据库共用的方式。

测试环境搭建需要考虑与生产环境的联系：架构、机型、中间件、系统参数、数据库

3、性能测试指标

交易响应时间（RT）：推荐响应在1s一下
TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。推荐500 TPS~10000 TPS，越大越好
QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒
并发用户（VU）：并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量

资源指标
CPU：主要指的CPU使用率
Memory：内存利用率
云盘使用率：磁盘使用率
IOPS：磁盘每秒读写次数(次/s)
云盘读写BPS：侧畔读写的数据量Byte/s
网络吞吐量：无网络故障的情况下单位时间内通过的网络的数据量（内网/外网）。单位为Byte/s

中间件指标
GC频率：每秒多少次，Java虚拟机垃圾部分回收频率
Full GC频率：每小时多少次，Java虚拟机垃圾完全回收频率，FULL GC不能频繁，JVM最小堆大小和最大堆大小分别设置1024 M比较合适
Full GC平均时长：秒，用于垃圾完全回收的平均时长
Full GC最大时长：秒，用于垃圾完全回收的最大时长
Active Thread Count：个，活动的线程数，线程数最小值设置50和最大值设置200比较合适
JDBC Active Connection：个，JDBC活动连接数，JDBC最小值设置50和最大值设置200比较合适

数据库指标
SQL：执行SQL耗时
TPS：每秒事务次数
命中率：命中率越高越好

前端指标
首次显示时间：在浏览器地址栏输入URL按回车到用户看到网页的第一个视觉标志为止
完全载入的时间：所有onLoad JavaScript处理程序执行完毕，所有动态的或延迟加载的内容都通过这些处理程序触发的时间
连接时间：连接时间就是浏览器与Web服务器建立TCP/IP连接的时间
服务器时间：服务器处理时间

稳定性指标
最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。至少保证系统稳定运行24小时以上

• TPS曲线稳定，没有大幅度的波动。
• 各项资源指标没有泄露或异常情况。

4、可能存在的性能瓶颈

1、硬件、规格上的瓶颈
一般指的是CPU、内存、磁盘I/O方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）。

2、中间件上的性能瓶颈
一般指的是应用服务器、web服务器等应用软件，还包括数据库系统。 例如：中间件weblogic平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。

3、应用程序上的性能瓶颈
一般指的是开发人员开发出来的应用程序。 例如，JVM参数不合理，容器配置不合理，慢SQL（可使用阿里云APM类产品如ARMS协助定位），数据库设计不合理，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够、无缓冲、无缓存、生产者和消费者不协调等），造成系统在大量用户访问时性能低下而造成的瓶颈。

4、操作系统上的性能瓶颈
一般指的是windows、UNIX、Linux等操作系统。 例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。

5、网络设备上的性能瓶颈
一般指的是防火墙、动态负载均衡器、交换机等设备。当前更多的云化服务架构使用的网络接入产品：包括但不限于SLB、WAF、高防IP、CDN、全站加速等等。 例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。

5、性能测试流程管理

性能测试的出发点（具体性能测试的策略还是需要细细研究，和实际业务相关）：

1、在测试阶段，在测试环境进行测试。单元测试时针对接口做性能测试，集成测试时针对整体做压测

2、在新品发布等高并发场景之前，对于正式环境的主要接口做性能测试

6、性能测试方法（具体看阿里云文档）

这边我推荐阿里云的PTS性能测试服务，可以满足压测的日常能力，且费用不高，阿里云文档：https://help.aliyun.com/document_detail/29262.html

PTS有以下优点

1、相比较开源产品JMeter，PTS学习成本低，无需自己安装，适合没这方面经验的人员快速上手

2、有比较好的接口管理功能，适合团队使用

3、方便监控阿里云服务，能提供梯度压测策略

4、压测结束后有压测报告，可视化程度高

以下我以正式环境的商品热搜管理接口为例，在PTS做性能测试
1、登录阿里云控制台，创建PTS压测

2、增加一个API接口，这边支持多个接口多个模板，我这边就一个API接口，填写接口信息

3、调试一下API

4、填写施压配置，具体参数说明请看阿里云文档，我这边列上我的参数

5、填写高级设置，这边填上我的配置

6、在压测监控增加要监控的slb、ecs、RDS信息，我这边监控线上的两台服务器

7、填写SLA定义，SLA是判定压测是否异常的重要依据，发现异常自动化终止压测。原则上正式环境压测必须要配SLA，我这边因为并发量很小就没有配

8、调试下场景，没有问题后就点击保存去压测