一、常用性能指标
1、并发用户数：
指同一时间点对系统进行操作的用户数。准确说为"同时向服务器发送服务请求,给服务器产生压力的用户数量"
并发用户数和注册用户数、在线用户数的概念不同：
并发用户数一定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，不一定对服务器不产生压力，注册用户数一
般指的是数据库中存在的用户数。
2、每秒事务数(TPS)/每秒查询率(QPS)
2.1、TPS(Transactions Per Second)：每秒事务事，单位时间内处理的事务数量，它表示系统的处理能力。
事务是一个或者多个操作的集合，可以一个接口、多个接口、一个业务流程、多个业务流程等等。
2.2、QPS(Queries Per Second):每秒查询率，是一台服务器每秒能够响应的查询次数(数据库中的每秒执行查询sql的次数)
2.3、区别：
如果一个事务，调了1个接口，且这个接口内部不会再去请求其它接口，那么tps=qps，否则，tps≠qps
3、响应时间（RT）
指客户端发起服务请求到服务器处理完服务请求并返回结果给客户端的时间。
4、 吞吐量（Throughput）
指的是单位时间内处理的客户端请求数量。
4.1、从业务角度来看，吞吐量指每秒事务数。单位：“Requests/Second”
4.2、从网络角度来看，吞吐量指每秒字节数，用来衡量网络的流量。单位：“Bytes/Second”
二、性能指标评估
1、背景
做性能测试之前，最好先定义清楚性能指标。这样我们才能评估测试结果是否满足预期。最理想的情况是，开发、产品、
项目经理已经提前定义好性能指标。但是理想和现实的差距非常大。
2、获取性能指标
如果用户有明确的性能指标，直接使用即可；如果没有，首先要进行需求分析，以获取满足要求的性能指标，
如通过业务调研、日志信息等获取系统最大在线用户数、业务分布、业务高峰时间段、业务高峰期业务量等
3、性能指标计算/统计方式
3.1、性能测试范围：通过业务分布来确定性能测试的范围
3.2、并发用户数评估
(1)、通过TPS来估算并发用户数
并发用户数 = TPS*(RT+Think Time) 备注：TPS根据业务调研、需求分析可以计算
(2)、通过在线活动用户数来估算并发用户数
平均并发用户数：C=nL / T
备注：n是平均每天访问用户数（login session的数量），L是一天内用户从登录到退出的平均
时长（login session的平均时间），T是考察时间长度（一天内多长时间有用户使用系统）
并发用户数峰值：
C是平均并发用户数，该公式遵循泊松分布理论。
举例，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统
日志从获得），对于 一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天
之内，用户只有在8小时之内会使用该系统。
平均并发用户数为：C = 400*4/8 = 200
并发用户数峰值为：C‘ = 200 + 3*根号200 = 243
(3)、通用公式
对绝大多数场景，我们用（用户总量/统计时间）*影响因子（一般为3）来进行估算并发量。
比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，
根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为：
50000*80%/（3*60*60）=3.7
约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人
需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大！
(4)、根据系统在线用户数计算
并发用户数 = 系统最大在线用户数的8%到12%
在进行并发用户数评估的时候，不仅要满足当前的性能需求，还要满足未来2~3年不断增长的业务量和用户量的需求。所以评估时候要考虑未来几年的业务增长率。
3.3、TPS(每秒事务数)：通过某时间段业务量的峰值来确定TPS(峰值才能真实反映服务器的最大处理能力)，TPS=总的事务数/总的时间
，中间可能会用到二八法则：指80%的业务量在20%的时间里完成。
3.4、响应时间评估
(1)、用户感知正常响应时间的标准
2-5-8原则：
1).如果响应时间在2s内，用户会觉得系统很快
2).如果响应时间在2~5秒之间，用户会觉得系统的响应速度还可以
3).如果响应时间在2~8秒之间，用户会觉得系统的响应速度很慢，但还可以勉强接受
4).而当超过8秒后仍无法得到响应时，用户会觉得系统糟糕透了，或认为系统已经失去响应
(2)、用户感知特殊响应时间的标准
1).普通业务操作响应时间：5秒内
2).万级数据量查询响应时间：8秒内
3).百万级数据量查询响应时间：10秒内
4).千万级别数据量查询响应时间：20秒内
(3)、公式计算
通过并发用户数 = TPS*(RT+Think Time)，来计算响应时间
3.5、事务成功率
单位时间内系统可以成功完成多少个定义的事务，在一定程度上反应了系统的处理能力，一般事务成功率要求100%或大于99%
3.6、系统资源使用率
(1).CPU使用率：指用户进程与系统进程消耗的CPU百分比，长时间情况下，一般不超过80%；
(2).内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，内存使用率一般不超过80%；
(3).磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写
IO操作，取数据的时候对应的是是读IO操作，一般使用磁盘用于读写操作所占用的时间百分比度量磁盘
读写性能；如：Linux命令：iostat -d -x # -d 显示磁盘使用情况，-x 显示详细信息
%util： 一秒中有百分之多少的时间用于 I/O
如果%util接近100%，说明产生的I/O请求太多，I/O系统已经满负荷
(4).网络带宽：一般使用计数器Bytes Total/sec来度量，其表示为发送和接收字节的速率，包括帧字符在内；判断网络连
接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较；
三、性能测试通过标准(参考)
性能测试通过标准包括服务端性能、前端性能和用户体验性能，常规通过标准如表所示:
1、通用互联网服务端性能
(1).TPS(每秒事务数)大于期望值
(2).响应时间小于期望值
(3).错误率小于0.5%(事务成功率大于99.5%)
(4).CPU使用率小于75%
(5).JVM内存使用率小于80%
2、用户感知正常响应时间的标准
2-5-8原则：
(1).如果响应时间在2s内，用户会觉得系统很快
(2).如果响应时间在2~5秒之间，用户会觉得系统的响应速度还可以
3.如果响应时间在5~8秒之间，用户会觉得系统的响应速度很慢，但还可以勉强接受
4.而当超过8秒后仍无法得到响应时，用户会觉得系统糟糕透了，或认为系统已经失去响应
3、用户感知特殊响应时间的标准
1.普通业务操作响应时间：5秒内
2.万级数据量查询响应时间：8秒内
3.百万级数据量查询响应时间：10秒内
4.千万级别数据量查询响应时间：20秒内
4、中间件的一些标准
1.当前正在运行的线程数不能超过设定的最大值
2.当前运行的JDBC连接数不能超过设定的最大值
3.GC频率不能频繁，特别是FULL GC更不能频繁，FullGC频率大于半小时每次。
5、全栈性能修炼宝典中的标准(借鉴)：
对于新项目、还未上线的项目：
建议：可以不要管什么性能指标，直接开始测试，测试完成后，将测试结果发送给相关人员进行评估，最终决定测试结果是否满足系统性能要求。
六、其它说明：
为什么要减少FullGC频率：FullGC会产生应用程序停顿，整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉。