工作近十年断断续续做过不少性能测试，使用过jemter ，公司自建的平台等压力测试工具。最近为应对公司618活动，最近shoppingbag 又进行了 重构，顾需要从服务端对api做一次性能评估。
公司的服务正好部署在aliyun上，自然联想到使用阿里云的pts saas服务。
系统的学习了一遍：
并发用户、RPS、TPS的概念及关系_性能测试-阿里云帮助中心
在性能测试中，通常有两种施压模式：并发模式和RPS模式。传统方式是使用并发用户数来衡量系统的性能（站在客户端视角）。此方法一般适用于一些网页站点的压测（例如H5页面）；而RPS（Requests per second）模式主要是为了方便直接衡量系统的吞吐能力TPS（Transaction Per Second，每秒事务数）而设计的（站在服务端视角），按照被压测端需要达到TPS等量设置相应的RPS，应用场景主要是一些动态的接口API，例如登录、提交订单等等。
如何获取VU和TPS
- VU获取方式：
已有系统：可选取高峰时刻，在一定时间内使用系统的人数，这些人数可认为是在线用户数，并发用户数可以取10%，例如在半个小时内，使用系统的用户数为10万，那么取10%（即1万）作为并发用户数基本就够了。
新系统：没有历史数据作参考，建议通过业务部门进行评估。
- TPS获取方式：
已有系统：可选取高峰时刻，在一定时间内（如3分钟~10分钟），获取系统总业务量，计算单位时间（秒）内完成的笔数，乘以2~5倍作为峰值的TPS，例如峰值3分钟内处理订单18万笔，平均TPS是1000，峰值TPS可以是2000~5000。
新系统：没有历史数据作参考，建议通过业务部门进行评估。
-
本次测试过程中踩过的坑：
-
因为购物袋中对某一个商品的加购 有99的上限限制，故写操作大批量request的时候，会出现促发上限误报异常
-
后端服务的接口不需要token验证，token的验证一般应该在接口层处理
-
写操作有分布式锁，故性能数据准备的时候一定要是多用户
