性能测试中会涉及很多性能相关的指标和术语，本节重点剖析核心的概念。
表示某个时间段内在服务器上保持登录状态的用户。但在线用户不一定是对服务器产生压力的用户，只有正在操作的活跃用户才会对服务器产生压力，在线只是一种状态。
类似活跃用户，表示某个时间段内与服务器保持交互的用户，理论上这些用户有同一时刻(即绝对并发)进行操作的可能(对这种可能性的度量称为并发度》。相对并发的说法主要是为了区分绝对并发。
表示同一时间点 (严格地说是足够短的时间段内)与服务器进行交互的用户，一般通过测试工具提供的并发控制 (如JMeter的集合点)实现。
表示用户每个操作后的暂停时间，或者叫作操作之间的间隔时间，此时间内用户是不对服务器产生压力的。如果想了解系统在极端情况下的性能表现，可以设置思考时间为0;而如果要预估系统能够承受的最大压力，就应该尽可能地模拟真实思考时间。
通常包括网络传输请求的时间、服务器处理的时间，以及网络传输响应的时间。而我们重点关心的应该是服务器处理的时间，这部分受到代码处理请求的业务逻辑的影响，从中可以真正发现缺陷并对业务逻辑进行优化，而网络传输请求和响应的时间很大程度上取决于网络质量。
响应时间也就是JMeter术语中的Elapsed time，表示接收完所有响应内容的时间点减去请求开始发送的时间点。另外，Latency time表示接收到响应的第一个字节的时间点减去请求开始发送的时间点,Connection time表示建立连接所消耗的时间。
当关注响应时间时，不应该只关注平均响应时间。通常我们会采用95%的响应时间，即所有请求的响应时间按照从小到大排列，位于 95% 的响应时间。该值更有代表性，而平均响应时间未能有效地考虑波动性
指每秒处理的事务数，是直接反映系统性能的指标。该值越大，系统性能越好。通常如果个事务包含的请求就1个，那么这个值就是每秒处理请求数。另外还有个概念叫吞吐量，它除了用于描述网络带宽能力，也指单位时间内系统处理的请求数量，JMeter聚合报告中TPS就是用该术语显示的。假如1个用户在1s内完成1笔事务，则TPS明显就是1; 如果某笔业务响应时间是1ms，则1个用户在1s内能完成1000笔事务，则TPS就是1000了;如果某笔业务响应时间是1s，则1个用户在1s内只能完成1笔事务，要想TPS达到1000，则至少需要1000个用户。因此在1s内，1个用户可以完成1000笔事务，1000个用户也可以完成1000笔事务，这取决于业务响应时间。
方差和标准差都是用来描述一组数据的波动性的 (表现数据集中还是分散)，标准差的平方就是方差。方差越大，数据的波动越大。
众所周知，性能测试依赖于特定的硬件、软件、应用服务和网络资源等，所以在性能场景执行期间TPS可能表现为稳定，或者波动，或者遵循一定的趋势上升或下降。由此可以根据离散系数提出一个TPS波动范围的概念，并定义为TPS标准差除以TPS平均值。如果这个比值超过了一定的范围，就认为这个性能点的TPS不够稳定，也间接证明被测系统的响应波动大，不满足性能期望。
另外，从上述的术语中不难发现，TPS、并发数与响应时间之间是有一定的关系的。假设平均响应时间为t (单位为毫秒)，并发量为 C，每秒处理请求数为 g，则g =(1000/t)x c 就是这个关系。所以想要升高 g ，就只有两条路: 降低t和升高 C。
对于降低t，只能靠优化代码方式来实现，这取决于软件工程师的编码水平或架构设计。
对于升高C，通常 c 与服务器程序的请求处理模型关系比较大。如果服务器程序是“一个线程对应一个请求”的模式，那么c 的最大值就受制于服务器能支撑多少个线程;如果是“一个进程对应一个请求”的模式那么c 的最大值则受制于最大进程数。另外，在升高c 值的过程中，不得不注意的一点是，随着线程/进程数增多，上下文切换、线程/进程调度开销会增大，这会间接地显著增大t 的值，因而不能让 g 的值跟着c 的值等比升高。所以一味增大 c 值通常也不会有好结果，最合适的 c 值应该根据实测试验得出。
有一种特殊情况: 若业务决定了该服务器提供的服务具有“数据量小、返回时间较长”的特征，即这是一个不忙但很慢的业务类型，那么可以采用NIO模式提供服务，例如Nginx就默认采用NIO模式。 在这种模式下，c 值不再与线程/进程数相关，而只是与“套接字连接数”相关。通常“套接字连接数”可以非常大，在经过特殊配置的Linux服务器上，可以同时支撑百万级别的套接字连接数，在这种情况下c 值可以达到100万。
在如此高的 c 值之下，就算 再大，也可以支撑一个很高的 q ，同时真正的线程/进程数可以只设置到跟CPU核数一致，以求最大化CPU利用率。当然，这一切的前提是该业务具有“数据量小、返回时间较长”的特征。
经过上述分析，在评定服务器的性能时，应该结合TPS和并发用户数，以TPS为主、以并发用户数为辅来衡量系统的性能。如果必须要用并发用户数来衡量，则需要一个前提一一交易在多长时间内完成。因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到脚本中，并发用户数基本可以增加一倍，所以用并发用户数来衡量系统的性能没太大的意义。
本文链接：http://www.28at.com/showinfo-26-10498-0.html性能测试中的指标和术语
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 让程序员告别996，这款开发工具火了
下一篇： 如何分析性能测试中的基础曲线模型
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
