本文记录性能测试相关思路，仅供参考，不断更新中~
目录
测试工具理论
1.以Jmeter为例，脚本中的所有组件，都需要线程去执行，线程不只是执行请求操作，这就消耗了测试机的资源，而且对并发也有损耗，所以脚本的组件不能添加太多，要么就二次开发工具
2.压测工具本身也有性能差异，在大并发下，工具处理压力也相当于一个服务器系统，如果工具的并发性能小于服务端系统，那测试效果就比较失真。严格来说，单机并发越高，测试数据越失真
集合点/同步定时器
集合点作用：将线程约束在一个极短时间内同步发送请求，制造短时高并发；
默认情况下，且没有其他削弱并发强度的设置，性能测试工具本来就是高强度的并发，不需要设置集合点。
以下场景可以设置集合点：
1.固定并发数：比如总共1000线程，设置500个线程周期性同步并发
2.固定场景并发：比如多接口情况下，总共1000线程，单独对某些接口设置500线程同步并发
集合点的缺点：
1.若使用不恰当，集合点反而会降低测试结果的性能数据，
2.因为线程需要等待指定的集合数量，才会发起请求，如果接口响应时间很慢，这就让等待的线程浪费了等待的时间，而这个等待过程中对系统造成的压力减少，使得性能结果偏低。
3.而如果接口响应时间越小，也越没有必要加集合点，因为本身就是高并发请求。
4.也可以说，集合点就像宏观调控，调控不当也会阻碍自由市场的发挥
分布式
为什么jmeter要做分布式：因为单机不足以支持大并发：一个是配置问题，一个是端口数问题，主要还是配置问题，还没到6w连接 CPU内存就爆炸了
还有就是单机大并发，测试数据会失真（单机CPU并发处理有限，脚本组件过多也会有并发损耗）
Jmeter本身支持分布式，但是海量并发下jmeter的master可能存在瓶颈，可以采用Jenkins job来调度jmeter的分布式节点。
如果需要一千万并发，怎么测试：
看业务场景，具体有多少并发，TPS是什么水平，根据TPS需求设计测试方案；
从架构设计角度，可以适当限流削峰、业务缓冲，并发就不用那么高，减少系统压力和成本；
真的需要测那么高，就得分布式压测了，同时后端测试环境也得有相对应的配置
关于大并发，由于实际用户是分布在世界各地（各地到服务端时间不同），很少有对服务端大并发的情况；测试机单机，也不是完全的同一时刻发送请求（VU数越大，启动线程时间越长），所以需要分布式压测避免测试失真
线程数、并发用户数和并发强度
线程数=并发用户数？是的，我的理解是（当然如果你有些线程在测试过程中不做任何请求就不算并发数之一）；
需要注意的是，这里的并发用户是测试维度，不是业务维度的
根据所谓的狭义并发和广义并发概念，我对应理解为对服务端的高压并发和低压并发。不同压力下的并发数是不一样的效果的，也就是说，同样线程数下，并发强度取决于请求时间范围。
比如1000线程1秒内都进行一次请求，和1000线程5分钟内都进行一次请求，前者相对后者为高压并发（前提是后者请求确实是“均匀”的分布在5分钟内）。
比如同样1000线程，设置集合点可以看作高压并发，设置思考时间10s则为低压并发，两者并发数都可以说有1000个。
采取哪种并发模式，得看业务模型，比如说什么时间段用户多，用户集中操作什么业务，各业务比例多少
相关测试脚本配置有：集合点，思考时间，梯度加压，吞吐限制等
并发用户数的业务维度和测试维度
业务维度的并发用户，即实际系统运行时的客户端并发数；
测试维度的并发用户，即性能测试时设置的线程数（即Virtual User）；
业务维度和测试维度的并发用户数差异：
就拿一个经典场景来说：5分钟内有20000人进行钉钉打卡。
这个场景20000就是业务维度的并发用户数，相应的TPS为20000/300约等于66；
那么测试维度的并发用户数（即线程数）需要设置多少呢，不知道，需要测试了才知道。
这是因为，业务维度和测试维度的并发强度是不同的；需要设置多少线程，还需要看系统的性能
默认情况下，测试线程的并发强度是比较大的，如果系统性能足够，则只需少量线程即可达到业务的TPS水平
所以要设置多少线程数，取决于测试工具的设置（工具的设置决定线程的并发强度）和系统的性能
不同的需求，有不同的测试策略：
1.以一定并发用户数为目标
根据已知业务并发用户量，设置对等的并发强度的线程数，评估响应时间和TPS；
比如某产品有5000并发用户，则线程数设置5000
2.以一定TPS目标
根据目标TPS，以小量线程做试探性基准测试，逐步加压以达到目标TPS，并保证响应时间；
比如某产品现阶段5000用户，需达到5000TPS，则先设置100线程（也可以是其他数字）试探TPS水平，根据测试结果进行线程数调整
关于并发的失真度和测试准确度
性能测试的本质是：用少量测试机模拟大量客户端的请求，这就会存在测试与实际的误差。
即使是集合点也做不到严格的短时同时并发，因为CPU处理线程能力有限，需要集合的线程数越多、测试机配置越低，则CPU调度线程的负担越大、测试机花费在线程调度的时间越多、并发效果就越失真
所以，单个测试机启动的线程数越多，则实际测试达不到预期的压力效果、测试效果越失真
而且网络传输请求也会有时间损耗，到达服务端的时差越大，对服务端的平均压力越小，测试效果越差，不过这种损耗一般比较小
压测要持续跑一段时间吗，可以只迭代一次吗
只迭代一次不能保证测试结果的可靠，需要持续执行一段时间；
根据接口业务响应时间，响应时间慢则执行时间可以长一点。
压测持续时间长短有什么区别
如果是考察系统稳定性，则时间长短是不一样的；如果是普通压测，则时间持续到一定长度，让测试结果可靠就行。
即压测时间越长，越有几率发现系统异常、也越能体现系统稳定性。
业务时间和测试时间的区别
1）实际业务可能只有执行一次性请求，但是测试也要持续压测保证结果可靠；
2）如果某个业务持续5分钟，不是说跑5分钟就行，而是根据这5分钟之内的压力情况进行场景设计，测试时间必须大于5分钟
服务端连接数设置多少合理
这属于性能需求分析，基本来说就是，连接数太多，后面的响应时间就很长；连接数太少，客户请求直接被拒绝。安全上来说，需要限流，分流。客户体验来说，前后端业务和架构都要合理设计。
连接数其实也是个队列，只不过是OS和tomcat维护的，业务层面，还任务队列这些，比如你抢票，总不能tomcat连接数就那么多，直接拒绝客户请求吧，前端需要提示客户有多少人在排队，后端就是队列处理。也可以直接让客户稍后再试试，减轻服务端压力
也就是说，连接数设置多少，看实际情况和架构设计
容量规划与性能测试
系统的TPS上限、承受的请求量上限等即为系统容量；容量规划需要性能测试来保证；
预期容量：通过性能测试评估未上线的系统容量；或者根据当前线上系统容量，推算未来系统需要进行的容量调整
容量规划：做好限流熔断、系统降级、动态扩容的准备
怎样定义一个业务，业务比例怎么配置
业务定义：一个接口，一个事务，一个流程都可以作为一个业务，根据系统和实际使用情况而定义。一个接口就可以实现一个业务功能，则可以把一个接口当作一个业务；几个接口有强关联才能算一个业务，这就可以看作一个事务，一个业务整体；若要进行全链路压测之类的，可以对一些流程做流量回放
比例配置：比例配置有好几个基准，有线程数比例、请求比例、TPS比例、流量比例等。根据不同的系统场景，采用不同的测试策略，使用的比例基准自然不同
性能测试需要测试所有业务吗？
一般来说不需要，在需求分析阶段可以商讨出需要测试的业务范围，一般对热点业务和核心业务进行性能测试；如果有时间有资源有必要需求，可以进行全链路压测
何为压力，压单接口和多接口有什么区别？
只要向服务器发起请求了，服务器进行运算了，对服务器来说就都有产生压力，也就是说请求量越多服务器压力越大，但是服务器处理每个接口承受的压力是不同的，自然性能表现不同，可以假设每个接口对服务器有一个压力值。
1.所以客户端单线程压A接口和单线程压B接口对服务端造成的压力不同；
2.假设A接口和B接口的压力值相同，则客户端单线程压A接口和单线程压B接口对服务端造成的压力相同；
3.在条件2的基础上，如果用100线程压A接口，和分别用50线程压A接口50线程压B接口，两个场景的性能表现可能相同
4.如果AB接口压力值不同，则条件3的场景性能表现则不同
只用一个账户做压测和多个账户压测的区别
针对登录请求：
数据库查库、注册中心校验账号密码（解密），生成token、redis缓存用户token快慢的区别
针对非登录请求：
redis缓存用户token、校验用户token、各种缓存、数据库查表（比如查用户订单）多少的区别；
具体看业务在后台的处理方式，比如针对不同用户做日志记录，数据库表越复杂则影响越大；
用户数据越多，缓存的数据量也越多，系统预热的准备时间也不同。
必须用户参数化的情况：
IP限制，单端登录，token唯一、登录次数限制、特殊业务需求
系统预热的必要性
由于压测刚开始的时候，系统还没有针对热点数据做好缓存，测试的响应时间或者TPS的指标可能比较低，所以需要做系统预热，让测试持续进行一段时间，使系统趋于稳定的表现。
梯度加压设置的作用
压力梯度设置是为了监视系统资源调度能力（如梯度减压过程，资源的释放情况），系统动态处理能力，也可以在特定场景模拟真实场景
参数化作用
1、参数化逐行读取解决数据无法重复使用问题；
2、使用参数化达到发送随机数据的目的；
3、提前准备数据用来参数化，解决接口关联问题；
792
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
