前言

服务端性能测试在目前绝大部分公司都开始做了,大部分是使用的 jmeter、lr、gatling 等工具.

不过本文提到的压测工具是阿里云的 pts 压测工具,当然我不是 pts 的托.

只不过 pts 相比 jmeter、lr 等工具,是在太易用了.尤其在创业团队,搭建压测环境、全链路压测是一件麻烦的事,压测只是工作的一小部分,没必要把时间浪费在环境上 (公司有钱),所以当时考虑使用 pts 工具.

官网: https://pts.aliyun.com

当然压测工具就是工具而已,核心还是需要懂压测相关知识和服务端知识.

知识铺垫

这个思维导图是整理了服务端相关的基本知识,可以自行科普下

项目介绍

本次使用的是"jpetstore"项目,一个在线购买宠物的商店的网站.

项目基本功能是首页、搜索、产品、购买、下单,和现在的电商没太大差别.

环境搭建

源码地址

https://github.com/mybatis/jpetstore-6.git 

构建编译

./mvnw clean package

会在 target 目录下生成 jpetstore.war

本地环境部署

./mvnw cargo:run -P tomcat90

生产环境部署

tomcat

需要先安装 tomcat,下载地址:https://tomcat.apache.org

把下载的 tomcat.zip 包放到服务上并且解压.

把 jpetstore.war 放到 tomcat 的 apache-tomcat-9.0.22/webapps 目录下

启动项目

赋予 shell 脚本权限

cd bin && chmod 777 *.sh

启动 tomcat 命令

cd bin && sh startup.sh

查看启动日志和进程是否存在

cd /root/apache-tomcat-9.0.22/logs &&  tail -100f catalina.2019-08-13.log

网站地址:

http://home.nickxin.top:8080/jpetstore/

压测场景

压测接口

接口列表一般由服务端开发提供,说明本次压测接口、参数、预期 qps.

预期 qps 一般也是从产品给出的 pv 或者某个业务场景的使用量大致评估出来的.

所以我们压测的目的就是看这个接口能不能满足预期 qps.

接口列表:

序号 描述 接口地址 请求类型 参数
1 首页 http://home.nickxin.top:8080/jpetstore/actions/Catalog.action get
2 进入登录 http://home.nickxin.top:8080/jpetstore/actions/Account.action?signonForm= get
3 登录 http://home.nickxin.top:8080/jpetstore/actions/Account.action post username=j2ee&password=j2ee&signon=Login
4 产品列表 http://home.nickxin.top:8080/petstore/actions/Account.action get
5 型号列表 http://home.nickxin.top:8080/jpetstore/actions/Catalog.action?viewProduct=&productId=FI-SW-01 get
6 型号详情 http://home.nickxin.top:8080/jpetstore/actions/Catalog.action?viewItem=&itemId=EST-1 get
7 加入购物车 http://home.nickxin.top:8080/jpetstore/actions/Cart.action?addItemToCart=&workingItemId=EST-1 get
8 提交订单 http://home.nickxin.top:8080/jpetstore/actions/Order.action?newOrderForm= post
9 确认订单 http://home.nickxin.top:8080/jpetstore/actions/Order.action?newOrderForm= get
10 订单详情 http://home.nickxin.top:8080/jpetstore/actions/Order.action?newOrder=&confirmed=true get

服务器配置

现在大多数公司都使用云服务了,一般会使用 docker 技术把服务打包成镜像部署.

使用 docker 部署的好处在于,可以随时横向扩展实例,达到秒级部署.

当然 docker 部署也是使用宿主机的硬件,所以一般需要宿主机硬件能力比较强.

压测模型

压测模型一般来源于真实的业务场景串联,比如 首页 ->列表 ->详情 ->支付.

这个链路中流量是漏斗效应.

接口响应时间

互联网企业: 500ms
金融企业: 1s
保险企业: 3s

互联网企业中其实很少超级复杂的计算,一般耗时在 db 上或者调用第三方接口.

调试

在把所有用例写完之后,需要预先调试一次,保障每个接口是可用的.

压测过程

这次压测我们使用 RPS 的方式压测,相比并发方式结果更好计算和评估测试结果.

如果是按照并发方式计算:

user = qps * rt

100 = 200 * 0.5

业务监控

需要关注接口的平均响应时间、错误次数、返回数据是否正常等.

偶现的一些错误数据可以忽略.

服务器监控

压测过程不仅需要关注业务,也需要监控服务器硬件指标.

一般包括内存、cpu、网络流量、db 连接数、redis 带宽.

压测数据隔离

1.有写库的请求,把测试数据写入影子表,通过 header 头字段标示

2.如果没有影子表,可以给指定账号写数据,然后统一产出数据 (操作比较危险)

压测请求隔离

1.为了不影响线上用户,可以通过负载均衡挂载隔离

2.可以通过一些白名单策略隔离

压测报告

pts 压测完成后也提供了压测报告,包括平均响应时间、请求数量、压测阶梯图表.

当时 pts 的压测报告相对还是比较专业,给开发同学或者人员不是通俗易懂.

所以我们在压测完成会把本次压测过程记录在 wiki 上,并标明"压测结论".

学习文档

淘宝服务端高并发分布式架构演进之路
https://mp.weixin.qq.com/s/HK3MmQDybmapUsDqUIc_CA

压测环境的设计和搭建
https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247486698&idx=3&sn=c3a2af9322c2bf6ad25d8c4823d1461f&chksm=fdeb3e8aca9cb79c3ff4f0d61eed4db4e7fd72c54e0ef670ad9d4c12caa05000dec80bbd179a&scene=21#wechat_redirect

并发模式与 RPS 模式之争,性能压测领域的星球大战
https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247487138&idx=1&sn=be66769443f8157461c9ef12cba7722c&chksm=fdeb3cc2ca9cb5d423dceb71977e01a07be3be552a9b7cc63afec96936ee0b14ef07ff602345&scene=21#wechat_redirect

实战讲述性能测试场景设计和实现
https://mp.weixin.qq.com/s/u0d-tgP3zkmb8MRzyBgQlw

阿里巴巴在开源压测工具 JMeter 上的实践和优化
https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247487005&idx=1&sn=9c8837261ce97f69f019fe909e09e789&chksm=fdeb3c7dca9cb56b6c142d52f08eae5143cfc38bf214c2e716f65202f83ffd9325b845da48dc&scene=21#wechat_redirect


↙↙↙阅读原文可查看相关链接,并与作者交流