在线用户
表示某个时间段内在服务器上保持登录状态的用户。但在线用户不一定是对服务器产生压力的用户,只有正在操作的活跃用户才会对服务器产生压力,在线只是一种状态。
相对并发用户
类似活跃用户,表示某个时间段内与服务器保持交互的用户,理论上这些用户有同一时刻(即绝对并发)进行操作的可能(对这种可能性的度量称为并发度》。相对并发的说法主要是为了区分绝对并发。
绝对并发用户
表示同一时间点 (严格地说是足够短的时间段内)与服务器进行交互的用户,一般通过测试工具提供的并发控制 (如JMeter的集合点)实现。
思考时间
表示用户每个操作后的暂停时间,或者叫作操作之间的间隔时间,此时间内用户是不对服务器产生压力的。如果想了解系统在极端情况下的性能表现,可以设置思考时间为0;而如果要预估系统能够承受的最大压力,就应该尽可能地模拟真实思考时间。
响应时间
通常包括网络传输请求的时间、服务器处理的时间,以及网络传输响应的时间。而我们重点关心的应该是服务器处理的时间,这部分受到代码处理请求的业务逻辑的影响,从中可以真正发现缺陷并对业务逻辑进行优化,而网络传输请求和响应的时间很大程度上取决于网络质量。
响应时间也就是JMeter术语中的Elapsed time,表示接收完所有响应内容的时间点减去请求开始发送的时间点。另外,Latency time表示接收到响应的第一个字节的时间点减去请求开始发送的时间点,Connection time表示建立连接所消耗的时间。
当关注响应时间时,不应该只关注平均响应时间。通常我们会采用95%的响应时间,即所有请求的响应时间按照从小到大排列,位于 95% 的响应时间。该值更有代表性,而平均响应时间未能有效地考虑波动性
TPS
指每秒处理的事务数,是直接反映系统性能的指标。该值越大,系统性能越好。通常如果个事务包含的请求就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不够稳定,也间接证明被测系统的响应波动大,不满足性能期望。
另外,从上述的术语中不难发现,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为主、以并发用户数为辅来衡量系统的性能。如果必须要用并发用户数来衡量,则需要一个前提一一交易在多长时间内完成。因为在系统负载不高的情况下,将思考时间(思考时间的值等于交易响应时间)加到脚本中,并发用户数基本可以增加一倍,所以用并发用户数来衡量系统的性能没太大的意义。
提示
- 高并发
并发强调多任务交替执行,并发与并行是有区别的,并行是多任务同时执行。例如,一个核的CPU处理事务就是并发;多个核的CPU就会存在事务的并行处理。这里涉及的知识点包括多线程、事务和锁,设计高并发通常采用无状态、拆分、服务化、服务隔离、消息队列、数据处理和缓存等。 - 高可用
用系统的无故障运行时间来度量,主要作用为保证软件故障监控、数据备份和保护、系统告警、错误隔离。业务层设计包括集群、降级、限流、容错、防重和幂等。数据库设计包括分库、分表和分片等。