服务器端和移动端性能测试指标

一、系统性能测试指标
01、并发
并发是指多个用户在同一时期内进行相同的事务处理或操作。由于用户在进行一系列操作流程时有一定的时间间隔（即用户思考时间）或者服务器处理请求有先后顺序，于是，就产生了绝对并发和相对并发概念的区分。
绝对并发是指同一时刻（即同一时间点）并发用户对服务器同时发送请求。
相对并发是指一段时间内（即同一时间区间）并发用户对服务器发送请求。

并发数计算公式
TPS=并发数/响应时间（基础公式）
并发数=TPS响应时间，即（全天业务笔数80%/操作业务的时间区间-秒20%，原则是80%的请求在20%的时间内完成）（期待响应时间+操控业务的平均单笔时间）

我们以实际数据量来计算：
收费业务按照2000人次每天计算，假设都在上午2小时内（7200s）集中完成收费操作，在UI页面中平均处理收费业务的时间是10s，完成收费的期待响应时间是3s。
那么根据公式计算的结果是：
并发数=TPS（2000乘80%/7200乘20%）* 响应时间（3秒+10秒）=14.44约等于15。

根据公式计算，15个并发已经满足测试需求，假设预计未来两年内业务会翻倍，那么并发数就是30，以此类推。。。

02、响应时间
响应时间（RT）,一般用平均响应时间（ART）
90线：所有请求的响应时间，从低到高进行排序，总量的90%的响应时间，一般有90%、95%、99%

是指某个请求或操作，从发出到接收到反馈所消耗的时间，包括应用服务器（客户端）处理时间、网络传输时间以及数据库服务器处理时间
所以：网络传输时间越接近0，响应时间就会越接近 服务器内部处理时间
即：性能测试，尽可能独立网络，尽可能用局域网，不要用无线网络

从用户的角度评价系统的处理速度，一般使用2-5-10原则

TPS（Transaction Per Second）每秒处理事务数，是指单位时间（每秒）系统处理的事务量。如：产品计算密集型，期望服务的处理能力越高越好，即侧重观察TPS指标
QPS（Query Per Second）是指单位时间内查询或访问服务器的次数。
针对单个接口而言：请求次数：查询次数=1：K (K≥1）

RPS是指用户端单位时间内的请求次数
HPS是指用户端单位时间内的点击次数
TPS和QPS的区别在于一个事务可以包含多次查询或访问服务器，也可以只查询或访问一次服务器。当多次查询或访问时，一个TPS相当于多个QPS；当只查询或访问一次时，一个TPS则等价于一个QPS。

PV（Page View）是页面的浏览量或点击量，用户对系统或者网站任何页面的每一次点击或者访问都会被记录一次浏览量或点击量，对相同页面进行多次访问浏览量或点击量也会进行累计。
UV（Unique Vistor）是系统或者网站的独立访客，一段时间内相同客户端（或PC）访问系统或者网站只会被记录一次，连续重复访问或者浏览多个系统页面次数不会进行累计。

03、吞吐量/吞吐率
吞吐量是指系统处理客户请求的字节数量的总和，可以指网络上传输数据包的总和，也可以指业务中客户端与服务器交互数据量的总和，是个泛概念
可以从服务器带宽、客户端带宽两个角度评估（100M带宽其实是12.5M），可关注硬盘IO、网络IO、CPU/内存、请求处理能力、单位打开页面数量等。

吞吐率是指单位时间内系统处理客户请求的数量，也就是单位时间内的吞吐量，单位一般是KB/S

可以从多个维度衡量吞吐率：
①业务角度：单位时间（每秒）的请求数或页面数，即请求数/秒或页面数/秒；
②网络角度：单位时间（每秒）网络中传输的数据包大小，即字节数/秒等；
③系统角度，单位时间内服务器所承受的压力，即系统的负载能力。
吞吐率（或吞吐量）是一种多维度量的性能指标，它与请求处理所消耗的CPU、内存、IO和网络带宽都强相关。

04、服务器性能指标
CPU
CPU使用率是单位时间内服务器CPU的使用统计，一般情况下，如果%us+%sy<=70%，我们可以认为系统的运行状态良好。
常用命令：
top
cat /proc/cpuinfo          //获取CPU详情

内存
Linux的系统内存管理机制遵循内存利用率最大化的原则。内核会将空余的内存划分为cached（不属于free），对于有频繁读取操作的文件或数据会被保存在cached中。因此，对于linux系统来说，可用于分配的内存不止free的内存，同时还包括cached的内存（其实还包括buffers的内存）。cached和buffers都属于缓存，它们的区别主要在于cached主要用来缓冲频繁读取的文件，它可以直接记忆我们打开的文件内容；而buffers主要用来给块设备做的缓冲大小，只记录文件系统的metadata以及tracking in-flight pages信息，比如存储目录里面的内容，权限等。
常用命令：
top
free –h

磁盘读写
常用命令: #fdisk –l          //查看硬盘及分区情况
命令：# df –h          //查看文件系统的磁盘空间使用情况
命令：#iostat    //主要用于输出磁盘IO 和 CPU的统计信息。

缓存
缓存是现在系统中必不可少的模块，并且已经成为了高并发高性能架构的一个关键组件。

Web缓存
可以理解为Web资源在Web服务器和客户端（浏览器）的副本，其作用体现在减少网络带宽消耗、降低服务器压力和减少网络延迟，加快页面打开速度等方面

数据缓存
当用户请求增多时，数据库的压力将大大增加，通过缓存能够大大降低数据库的压力，读写请求先在缓存中操作，然后在同步到数据库

系统负载
系统平均负载被定义为在特定时间间隔内运行队列中的平均进程数。如果一个进程满足以下条件则其就会位于运行队列中：
它没有在等待I/O操作的结果
它没有主动进入等待状态(也就是没有调用'wait')
没有被停止(例如：等待终止)
一般来说，每个CPU内核当前活动进程数不大于3，则系统运行表现良好！

常用命令:
uptime
显示：17:36:27 up 178 days,  6:10,  1 user, load average: 0.03, 0.09, 0.12
当前时间是17:36:27
系统已运行的时间178days, 6:10
当前在线用户1 user
平均负载：0.03, 0.09, 0.12，最近1分钟、5分钟、15分钟系统的负载

二、app性能指标

启动速度
冷启动速度：当启动应用时，后台没有该应用的进程
热启动速度：在后台已有进程的情况下启动
无网启动速度

流量：
标准为不必要的请求不发，有必要发的请求不重复发，频繁发的请求尽量精简，重复下载率为0

耗电量
Android 从两个层面统计电量的消耗，分别为软件排行榜和硬件排行榜。它们各有自己的耗电榜单，软件排行榜为机器中每个 App 的耗电榜单，硬件排行榜则为各个硬件的耗电榜单。这两个排行榜的统计是互为独立，互不干扰的。

卡顿（流畅度）：
卡顿顾名思义就是使用app的流畅度，主要涉及FPS和GPU渲染：
FPS(Frames Per Second的简称缩写)，意思是每秒传输帧数，也可以理解为1秒内游戏画面或者应用界面真实平均刷新次数，俗称帧率/FPS，一般每秒钟帧数越多，所显示的动作就会越流畅，FPS值越低就越卡顿，所以这个值在一定程度上可以衡量应用在图像绘制渲染处理时的性能。
通常，要避免动作不流畅的最低阈值是30/FPS，iOS系统中正常的屏幕刷新率为60Hz(60次每秒)。
理想情况下，移动端达到流畅画面需要60FPS，首页平均帧率45FPS，列表页平均帧率55FPS。

GPU渲染
GPU渲染是指在一个像素点上绘制多次（超过一次）：显示一个什么都没有做的activity界面算作画了1层，给activity加一个背景是第2层，在上面放了一个Text View（有背景的Text View）是第3层，Text View显示文本就是第4层。仅仅只是为了显示一个文本，却在同一个像素点绘制了四次,这是一定要优化的。过度绘制对动画性能的影响是极其严重的，如果你想要流畅的动画效果，那么一定不能忽视过度绘制。

三、其他
1、基准测试：第一次性能测试，得到的性能指标数据，如：TPS等，后续可以以此为参考，验证性能调优结果是否达到预期要求。
做基准测试所用的并发用户数，可以采用负载测试的方式得到。

2、负载测试：逐步增加并发用户数（如步长为10），观察性能指标参数，通过这些数据的实时展现，判断何时达到服务瓶颈。
判断瓶颈的指标标准：1、平均响应时间<1.5秒;2、错误率<0.1%；3、资源利用率<80%
三个指标有1个不满足时，即可大致确定服务瓶颈的并发用户数区间值，如【500-510】，然后开启第二轮负载测试，缩小步长（如步长为1），从而最终得到具体的最大可接受的并发用户数。
得到服务瓶颈的具体并发用户数数值后，即可用这个并发用户数来做性能测试，把结果记录下来，作为测试基准。

负载测试得到的最大用户数，代表着服务器能承受的最大用户数的同时请求量，与多少个用户访问系统无关。因为用户访问系统不一定时时在请求，有可能在“挂机”。

3、压力测试：长时间的性能测试，并发用户数一般选择最大可接受并发用户数的【20%-80%】区间的值，通过长时间来发现服务器是否存在不稳定的问题，以前一般采用7*24小时，现在一般以小时为单位
4、稳定性测试：并发用户数一般选择最大可接受并发用户数的【80%-无穷大】区间的值
压力测试与稳定性测试的差异：相对稳定性测试，压力测试的并发用户数较低。

5、容量测试：测试数据库中数据量级不同的时候，服务性能表现的差异。关注最大支撑的数据数量（如用户数、数据等）。
6、配置测试：更改服务的关键参数之后所做的性能测试

四、常见测试标准
超时概率：小于0.5%（百分之0.5）
错误概率：小于0.5‰（千分之0.5），又有说法是行业可接受范围在0.1%以内
CPU using：小于75%，又有说法是行业可接受范围小于80%
TPS：大于期望峰值
RT：小于期望时间，又有说法是行业可接受的ART在1.5秒以内
Load：平均每核CPU的load小于1
JVM Mem using：小于80%
Full GC频率：平均大于半小时1次

前端：YSlow评定，C级或C级以上
网页响应时间：1（优秀）-3（普通）-5（忍受极限）