1、需加集合点，模拟用户瞬间并发，对服务器冲击力大
3、每3秒进5个人，用户达到305080集合后分别压测，然后利用二分法不断取中间值，找出最大吞吐量
并发用户数
1、并发用户数标准不能以注册用户数为标准，应以在线用户数为标准或同时发请求用户更准，或注册用户数20%
2、并发用户数=系统总用户数20%—30%
4、每隔5分钟增加一定的并发数，直到达到瓶颈数，即线程数增加了以后tps处理量不在增加了，这个线程数可以算成合理的并发数。
负载测试
1、不加集合点，逐渐增加用户到系统瓶颈。对服务器冲击力小
3、逐渐增加用户，持续运行，直至达到系统瓶颈
稳定性测试
1、不加集合点，逐渐增加用户到最大负载量（负载测试最大点）
故障转移测试
恢复测试，是要把服务器压崩溃，测试另一台服务器是否可正常顶上
系统用户数（注册用户数）
在线用户数（相对并发用户数）
绝对并发用户
主要是针对某一个操作进行测试，即多个用户同一时刻发起相同请求,验证是否存在并发逻辑上的处理问题，如线程不安全、死锁等问题；也可提供一些性能上的参考
日常压力(日常数据分析)
测试场景，就是要用500个用户在4小时内完成“每人发一个帖子、浏览十个帖子”的工作量。
高峰期压力(日常数据分析)
是指系统正常的、预期内压力的一个高峰
峰值压力，不在正常预期内的压力
性能指标:
1、吞吐量
Tps是服务器每秒处理的事务字节数
4、CPU
中心处理单元，由控制单元和运算单元组成，对数据进行处理，并发出控制命令，协调周边设备运行，对数据判断极逻辑处理，不能存储数据，从内存中读取数据进行逻辑计算，如果内存中没数据，才会从硬盘中读数据到内存，再进行逻辑计算，不能高于75%
5、错误率
6、内存
liunx内存工作原理，内存8g优先分出7g一部分分给应用，一部分分给缓存内存，放应用内存不足时，会把缓存内存优先分给应用
性能问题及其BUG
1、大数据量下，产生的性能问题
2、大访问用户量下，产生的性能问题
3、预估未来数据量，产生的性能问题
4、大结果集下，产生的性能问题
5、大复杂逻辑下，产生的性能问题
6、数据库产生的性能问题（未分库、未分表、未主从分离、数据库结构、SQL慢查询、实时查询、索引优化(建立主键或唯一索引、未使用联合索引)
7、性能缺陷：（并发错误、死锁、内存泄露）
8、cpu处于70%-100%之间波动
需求产生
分析用户是如何使用系统，用户对哪些业务性能比较敏感，系统的一些关键业务实现逻辑，从设计实现的角度来看哪些业务的性能可能存在隐患
通过友盟、阿里云、埋点、数据库、产品、运维等收集信息，分析系统、分析业务、分析用户行为等
注册用户数、在线用户数、日常压力、峰值压力、高峰期压力
1、产品、研发有明确需求
2、无明确需求，初次上线系统，需用同行系统数据，进行用户行为分析和商业数据结构的估算，利用性能估算推算，帮助决策，形成性能需求
4、无明确需求，系统关键模块、性能隐患模块、用户敏感性能模块，确定性能需求
5、无明确需求，根据用户的使用行为，使用习惯，确定性能需求
6、无明确需求，参考系统历史3个月/6个月/1年数据、用户历史行为，预测未来数据，确定性能需求
7、无明确需求，进行峰值测试或稳定性测试，测出系统的性能瓶颈，评估是否达到预期。
需求分析
1、系统类型、特点、架构和设计
2、深入理解被测系统，确定系统的关键业务模块，从设计实现逻辑确认性能隐患的模块、用户敏感的性能模块、用户使用行为，整理测试思路、制定测试方案、产生测试场景
3、如果没有明确的性能需求，则根据历史数据或类似系统，由项目组评估出性能指标；
4、进行峰值测试或稳定性测试，测出系统的性能瓶颈，评估是否达到预期。
测试准备
1、控制机、压测机、压测环境
2、测试数据、业务数据、测试性能模拟的压力数据、
3、数据来自生产环境、最大可能模拟生产数据
4、根据经验预估的数据、根据历史数据预估的未来数据
环境准备
1、操作系统、服务器配置分析，需了解系统的架构和设计
2、了解cpu信息
3、用户量（PV、PU、业务量）
4、服务器重启重置环境，干净的系统环境，无运行程序和脚本
5、负载机环境
6、测试环境要尽量的模拟生产环境
压测场景模拟（模拟所有可能发生的极端的访问情况）
基准测试、日常压力测试、峰值压力测试、绝对并发测试、稳定性测试
压测策略
2、负载测试，单个交易多个用户并发10，测试验证系统并发情况下是否有并发性的错误应用锁数据库锁
3、容量测试，多个交易按一定比例去配比再按一定的体度一定的梯度102030逐步去施压，到获得这个系统的性能拐点，资源站用达到很高
1、疲劳压测（稳定性压测），持续压测5小时，测试性能指标
2、并发压测，单接口瞬间启动100线程并发，测试性能指标
3、日常压测，根据每日数据分析，如：500个用户在4小时内完成“每人发一个帖子、浏览十个帖子”的工作量，测试性能指标
4、业务压测，多接口业务流程压测，测试性能指标
5、峰值压测（极限压测），测试最大并发量，测试性能指标
6、阶梯压测,逐渐改变线程数进行压测，性能指标
7、大数据压测，数据量过大进行压测，性能指标
8、负载测试，分别压测50、100、150时，性能指标
9、数据库读写压测
案例：
2、25线程，5s后启动5个线程，再每隔5s启动5个线程运行10s，达到10线程运行20s，每隔3s停5个线程
8、比如：一个系统日均1万人访问，一天平均3次/人，一般集中在每天晚上8点-10点，则我们可以算出每天1万人*3次/人=3万次请求，1天3万次请求集中在8点到10点3个小时之内，3万次请求集中在3小时之内，则平均每小时访问1万次请求，则每秒就是10000次/3600s大约为3次/s，即根据以往运营日志得出每秒钟3次请求，按照我们的并发峰值4倍的策略，则我们的性能指标可以定在4*3=12次/s，即我们的每秒处理事务数可以按照12次/s的基础来参考。
结果分析（硬件配置-操作系统-数据库-中间件-后端应用-前端应用）
1、服务器性能（哪些资源cpu占用过大、内存占用、硬盘占用、I/O读写）
2、Tps每秒处理事务个数每个事务处理的平均时长
4、数据库（或中间件）非常慢了
5、中间件无响应
JVM堆内存用满，不停的进行GC，导致响应超慢（但是还没有OOM，否则就报错了）处理HTTP请求的线程，都被占用或者锁住
6、系统响应慢、超时、失败
7、服务器挂掉
8、网络（防火墙是否开启、端口的访问、宽带是否有被限制、路由寻址、网络的时延）
9、代码性能
10、定位分析问题：
10-1、网络忙不忙网络延迟大不大网卡流量是不是达到网卡瓶颈
10-2、操作系统应用服务器和数据库服务器资源cpu、内存占用、io读写
10-3、数据库锁运行等待等
10-4、应用系统日志死锁wait
10-5、前端连接数是否正常
10-6、与运维确认是否开了流量控制
10-7、再尝试重启应用服务器和数据库服务器
性能调优
1、扩充服务器（网路、cpu、内存、硬盘、显卡、I/o）
2、代码调优
3、中间件
4、分库、分表、主从分离、数据库结构优化、SQL优化、索引优化(建立主键或唯一索引、使用联合索引)
4.1、SQL优化
大表左关联小表，很慢；小表左关联大表，很快
嵌套的子查询是很慢
5、多个服务器负载均衡、使用缓存服务器
6、设置虚拟内存
7、运维设置限流
8、添加缓存、图片资源压缩
测试报告
性能测试比对1每次版本性能测试比对2机器横向增加，增加前后性能测试的比对3性能优化优化前后的性能测试比对
如何确定系统性能测试tps需求标准？
已上线项目
未上线项目
二八定律（无历史数据参考）（日活用户*总请求数*80%）/（24h-（0-6h）*3600秒*20%）*系数（2-5之间）=tps
1、先预估系统每日总请求数，如果没有历史数据参考，一般是通过用户量或者其他关联系统来评估。
3、最终计算出来的结果为80w请求/12960秒=61左右。也就是说接口TPS满足61即可。
4、最后再乘以一个冗余系数2-5之间，提高预期指标，防止人为评估造成预期指标偏低情况。
可以通过对项目接口的峰值监控，来对比之前评估的算法结果，调整冗余系数，最终随着不断的数据积累，将会形成一套本项目的性能模型。