1、背景
1.1、项目背景
随着APP-DDB在线用户数的不断增长，也为了减少服务器的使用台数，降低成本，需要对DDB的性能进一步优化。
1.2、性能目标
1.2.1、根据DDB的业务特性，测试当前系统的单接口最大容量。
1.2.2、根据业务比例设计容量场景，充分利用当前资源，找到当前系统的性能瓶颈，并优化，以达到系统的最佳运行状态。
1.2.3、根据稳定性场景，判断当前系统可支持的系统最大累加容量。
1.2.4、根据异常场景，判断当前系统中的异常对性能产生的影响。
2、测试范围
2.1、需要测试的特性
只模拟从redis读取指令，并且向笔端发送指令的接口容量测试。
2.2、不需要测试的特性
不验证从APP端操作下载等功能->java服务->redis->消息服务器的完整流程的接口容量测试。
3、测试准则
3.1、启动准则
3.1.1、确定系统逻辑架构和部署架构与生产一致。
3.1.2、确定基础数据和生产一致或按模型缩放。
3.1.3、确定业务模型可以模拟生产真实业务。
3.1.4、环境准备完毕，包括：
a. 功能验证通过。
b. 各组件基础参数梳理并配置正确。
c. 压力机到位，并部署完毕。
d. 网络配置正确，连接通畅，可以满足压力测试需求。
3.1.5、测试计划、方案评审完毕。
3.1.6、架构组、运维组、开发组、测试组及相关专家人员到位。
3.2、结束准则
3.2.1、达到项目要求的性能需求指标。
3.2.2、关键性能瓶颈已解决。
3.2.3、完成性能测试报告和性能调优报告。
3.3、暂停/再启动准则
3.3.1、暂停规则
a、系统环境变化：举例：系统主机硬件损坏、网络传输时间超长、压力发生器出现损坏、系统主机因别的原因需升级暂停等。
b、测试环境受到干扰，比如服务器被临时征用，或服务器的其他使用会对测试结果造成干扰。
c、需要调整测试环境资源，如操作系统、数据库参数等。
d、该测试机型无法达到规划指标要求。
e、出现测试风险中列出的问题。
3.3.2、再启动规则
a、测试中发现问题得以解决。
b、测试环境恢复正常。
c、测试风险中出现的问题已解决。
d、环境调整完毕。
4、业务模型/性能指标/资源利用率指标
4.1、业务模型/测试模型
接口1：登录 - /login - 业务比例占5%
接口2：下载 - /download - 业务占比10%
接口3：播单 - /playlist - 业务占比15%
4.2、业务指标/性能指标
接口1：登录 - /login - 目标TPS - TPS标准方差 - 响应时间 - 响应时间方差
接口2：下载 - /download - 目标TPS - TPS标准方差 - 响应时间 - 响应时间方差
接口3：播单 - /download - 目标TPS - TPS标准方差 - 响应时间 - 响应时间方差
4.3、资源利用率指标
cpu idle 30%
memory 无剧烈抖动或严重飙升（无内存抖动、无内存泄漏、无oom）
5、系统架构图
5.1、系统技术栈
Java
PHP
redis
gitlab
5.2、系统逻辑架构图
APP->Java服务->Redis->PHP服务->DDB
5.3、系统部署架构图
无
6、性能实施前提条件
6.1、硬件环境
6.1.1、起压环境：4核8G 500G （使用free -h 查看内存）；测试工具的安装与调试
6.1.2、被压环境：4核8G 500G ；基础环境已搭建，代码已部署
6.1.3、线下线上机器部署情况要有一定比例 ，比如1/2，1/4
6.2、工具准备
6.2.1、测试工具
a、jmeter：获取压测数据
b、influxdb：采集数据到数据库
c、grafana：展示数据
6.2.2、监控工具
阿里云监控
6.3、数据准备
6.3.1、数据量的准备：一定要按生产等比例缩放或者和生产数据一致来准备数据（1、数据量过多或者数据量过少或者数据量不均匀，无法测出系统正常的容量。2、要根据实际的业务去准备测试数据，比如钉钉打卡，每天登录10次，打卡10次，肯定是不符合业务逻辑的；再比如商城购买商品，每个用户都购买同一款商品，或者每个用户循环购买同一款商品，肯定是不符合业务逻辑的。）
a、登录数据：1W
b、下载数据：10W
c、播单数据：10W
6.3.2、数据准备的方式：
a、数据库
b、redis
c、csv
7、性能设计
7.1、题外话：100个线程循环100次和1000个线程循环10次有什么区别？
压测是服务器对线程的处理能力。假设CPU每秒处理10000个线程。
a、设置100个线程循环100次，并发时间设置为1s，CPU刚好可以处理过来，吞吐量是137，不会影响服务器的性能。
b、设置1000个线程循环10次，并发时间设置为1s, CPU处理不过来，可能会导致线程出现排队的现象，吞吐量是83，影响服务器的性能。
7.2、场景执行策略
7.2.1、加压方式：阶梯加压和高并发加压
阶梯加压：通过不断的并发加压，验证不同并发下服务的处理能力。
阶梯加压的两个特点：连续和阶梯。
高并发加压：高并发加压，验证流量高峰时服务的处理能力。
高并发加压的适用场景：秒杀、限流等。说到秒杀场景，有人觉得用大线程并发是合理的，其实这属于认识上的错误。因为即使线程数增加得再多，对已经达到 TPS 上限的系统来说，除了会增加响应时间之外，并无其他作用。
下面来验证一下，阶梯加压和高并发加压有什么区别？（压了一下，不敢把公司服务器压到TPS上限。知道有这么个事儿就可以了。）
a、设置1000个线程，循环次数不限，并发时间设置为0：
b、设置30秒启动1000个线程，持续3分钟：
c、设置60秒启动1000个线程，持续3分钟:
7.2.2、场景递增策略一定要满足两个条件：递增+连续
7.2.3、业务场景：
a、基准场景：把单接口或者单业务压到最大TPS，然后来分析单接口和单业务的瓶颈点在哪里。
b、容量场景：按业务比例进行压测。容量场景的最大TPS是指最大的稳定TPS。
c、稳定性场景：两个关键点：稳定性场景的时长&用多大的TPS来执行。在执行稳定性场景时，完全可以用最大的稳定 TPS 来运行，只要覆盖了运维周期之内的业务容量即可。
d、异常场景：宕主机、宕网卡、宕容器、宕应用等。
7.3、监控设计：全局监控+定向监控
8、项目组织架构
8.1、性能项目经理
8.2、性能脚本工程师：负责编写性能测试脚本和场景执行
8.3、性能分析工程师：负责分析性能场景执行过程中遇到的性能瓶颈
8.4、架构师：负责支持性能分析
8.5、运维工程师：负责支持性能分析
8.6、业务方：确定性能项目的业务级需求
8.7、老板：理智的老板负责协调支持；不理智的老板负责指手画脚的捣乱
9、成果输出
9.1、过程性输出
9.1.1、脚本
9.1.2、场景执行结果
9.1.3、监控结果
9.1.4、问题记录
9.2、结果输出
9.2.1、性能项目测试报告
a、性能结果报告一定要有结论，而不是给出一堆“资源使用率是多少”、“TPS 是多少”、“响应时间是多少”这种描述类的总结语。你想想，性能结果都在这个报告中了，谁还看不见怎么滴？还要你复述一遍吗？我们要给出“当前系统可支持 XXX 并发用户数，XXX 在线用户数”这样的结论。
b、一定不要用“可能”、“或许”、“理应”这种模棱两可的词，否则就是在赤裸裸地耍流氓。
c、性能结果报告中要有对运维工作的建议，也就是要给出关键性能参数的配置建议，比如线程池、队列、超时等。
d、性能结果报告中要有对后续性能工作的建议。
9.2.2、性能调优报告：调优报告才是整个性能项目的精华，调优报告中一定要记录下每一个性能问题的问题现象、分析过程、解决方案和解决效果。
10、项目风险分析
10.1、业务层的性能需求不明确
10.2、环境问题
10.3、数据问题
10.4、业务模型不准确
10.5、团队间沟通协作困难
10.6、瓶颈分析不到位，影响进度
10.7、硬件资源有限
10.8、项目时间不可控，因为出了问题，并没有人支持，只能自己搞。
参考：高楼老师的课程
