背景
APP首页热门Tab添加作品推荐策略，根据当前用户的年龄、性别、关注的用户、是否看过、被推荐作品的各项优质指标等维度，推荐优质作品展示在列表内
基本概念
QPS
解释：系统每秒能够处理request事务的数量
QPS = 并发数 / 平均相应时间
并发数
解释：系统同时处理request/事务的数量
并发用户数
计算公式：C = nL / T
解释：n是平均每天访问用户数、L是一天内用户从登录到退出的间隔时间、T是考察时间长度（一天内多长时间内有用户使用）
请求相应时间
解释：从发起一个请求开始到服务器返回结果到客户端为止，这中间的耗时，通常是平均相应时间
吞吐量
解释：一次性能测试网上传输的数据量总和
吞吐率
解释：单位时间内网络上传输的数据量
吞吐率 = 吞吐量 / 传输时间
业务角度：单位“请求数 / 秒”
点击率
解释：每秒钟用户向服务器提交的http请求数
资源利用率
解释：服务器的CPU利用率和磁盘利用率
测试流程
1、明确接口的使用场景（属于APP内流量最大的tab）
2、了解服务器配置（确定QPS值的关键因素）
3、准备测试是数据（模拟大量真实用户请求服务）
4、使用Jmeter编写测试脚本，执行压测任务
5、配合运维查看压测服务器CPU及磁盘使用情况、配合开发查看被测系统接口的运行情况是否有错误日志的收集
准备测试脚本
1、获取用户ID和Token
根据用户手机号（参数化），发送验证码（可设置通用验证码，跳过此步），进行登录，并对接口返回进行提取用户ID和Token，保存到指定文件里
2、请求被测接口
使用Jmeter读取刚才存储到文件里的用户信息，请求推荐接口，添加察看结果树和聚合报告
3、准备清除浏览记录的脚本
因为推荐系统的内容曝光策略，用户批量请求推荐接口后之前优质的内容不会再次曝光，需要清空缓存数据
开始压测
1、并发100，持续60s，查看聚合报告
总请求数：730次，失败12次，平均响应时间：645ms，qps 13
失败原因：代码中日志较多、中台服务、业务服务、推荐服务之间调用和数据存储结构等不合理，数据池数据量设置的较大
解决方案：修改部分数据结构从map改为数组，部分调用逻辑优化，减少数据池处理数量从20000减少到3000
2、并发200，持续60s，查看聚合报告
总请求数：13411次，失败0次，平均响应时间：109ms，qps 226
3、并发200，持续120s，查看聚合报告
总请求数：总请求数：27874次，平均响应时间：84.43ms，qps 231.5
测试总结
通过理解研发的修复过程，大致可以理解为推荐逻辑的取数过程链路长且推荐逻辑较复杂，通过减少了数据池的数据量来提高QPS
测试环境为1台服务器，生产环境是4台服务器，200+QPS基本满足线上环境使用
qps tps计算：
正常情况下，我们都可以根据28原则 ，就是说百分之80 的请求在百分之20 的时间里完成。
计算方式：（总的日活数单用户请求量0.8）/(一个用户的访问时长（s）*0.2)
根据算出的qps或者tps，便可以算出并发数。
计算方式：并发数 = 响应时间（s）* qps
