你应该了解的系统性能指标

您所在的位置:网站首页 评价一个软件的指标有哪些 你应该了解的系统性能指标

你应该了解的系统性能指标

#你应该了解的系统性能指标| 来源: 网络整理| 查看: 265

前言

作为一个IT行业从业者,无论你是开发、测试还是运维或者产品经理,都应该或多或少对你熟悉的产品或者系统的性能有一定的认知。因为一个系统的性能指标很大程度上决定了你这个产品的竞争力,而了解它的性能特性对你深入熟悉你的产品有着莫大的好处。

01 什么是系统

维基百科的解释为:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体。 好像扯的有点远,但是今天我们要讨论的是作为一个程序员者每天都需要面对的软件系统,我们每天的开发、测试、运维都是围绕它而进行。一般而言,大多数软件系统都可以拆分为服务端和客户端两大部分。其中客户端主要负责:发送请求、和接收请求结果;而服务端则负责:接收并响应请求(处理请求)、发送请求结果。

一般软件系统中客户端与服务端交互示意图02 系统的请求链路

上图只是简单说明了一般软件系统中客户端跟服务端扮演的角色,那么我们在对系统的实际使用过程中,服务端对客户端请求的响应流程是什么样的呢,如下图所示:

一般软件系统的请求链路

上图描述了一般软件系统的请求链路情况(比如我们常见的web系统),图中中间的两部分,我故意用留白的虚线表示有些简单的系统可能没有这两层(比如用一个简单的客户端程序对MySQL数据库进行CRUD),也可能只有其中的一层(一个最为简单的微服务系统)。

客户端层:发送请求命令,常见的有PC客户端,手机客户端,或者是简单的命令行终端等;

负载均衡层:为了保证系统的高可用性、防止大流量将某个服务击垮,对于客户端的请求进行流量转发,该层不与客户端建立连接。这里既可以是硬件的负载均衡、也可以是软件的负载均衡,硬件的比如F5设备、软件的比如LVS、Nginx等;

WebServer层/server层:经过负载均衡层转发的流量会以一定规则发送到该层,该层主要负责对请求逻辑的处理,对于大流量的场景,该层一般是以集群形式运行;

DB层:该层用来存储与业务相关的数据,上一层的所有IO请求均会落到该层,设计上除了一般的数据库外,为了加速IO查询效率,减轻DB压力,可能会引入缓存数据库,为了应对大数据量,这里可能用分布式数据库。

03 性能指标种类

在上述整个请求链路中,你可能会关注如下几个性能指标:

客户端的RPS(request per second)是多少;系统的TPS(transactions per second)是多少;系统的QPS(query per second)为多少;系统的吞吐量又是多少;系统的响应时间(也叫时延)为多少;系统可承载的在线用户数为多少;系统的并发数为多少;

带着这几个疑问再来看待你面对的系统,相信你会对系统有一个更加全面深刻的理解,也许很多小伙伴会说,这些指标我知道啊,也经常听说。但是,知道跟听说过不能代表你就理解了它真正的含义

什么是RPS(request per second):

用来描述客户端每秒钟向系统(服务端)发送请求的数量,该指标用于描述客户端发送请求的能力,该能力只跟客户端的发送频率、软件逻辑以及客户端硬件配置有关,尤其受CPU、网络配置影响较大。

什么是TPS(Transactions per second):

指:对系统(服务端)而言,每秒钟处理的事务数量。即1秒钟内,系统(服务端)能够响应(完成处理)客户端请求并成功返回给客户端的事务总数。并且客户端对于不同的应用场景而言,T的解读是不一样的,一般而言可以有如下两种解读方式:

api级别的事务业务级别的事务

不同的解读方式,T的数量是不一样的。以网上购物为例,假如我下单购买一件商品,从业务上来说这是一次购物行为,T数量为1。但是如果从服务端api级别来看待,你触发一次购物行为,后端服务除了会调用订单服务的api外,还会调用库存服务的api以及积分服务的api,T的数量为3。如下图所示:

一次网购下单行为示意图

对于T来说,涵盖了对服务端的增、删、改、查的全部操作。该指标可以比较全面的用来反映系统的处理能力有多大

什么是QPS(query per second):

用来描述系统(服务端)每秒钟可支撑的查询数量,该指标最初用来描述RDBMS中每秒中执行的SQL数量,但是后来慢慢的就被用来描述系统的吞吐量了。也就是说我们现在通常说的系统QPS实际上说的是系统的吞吐量。由于只是描述查询的效率,因此该指标是用来描述系统(服务端)查询能力有多大的。相比于TPS,QPS只能反映系统(服务端)处理请求能力的一部分,可以理解为TPS的一个子集

什么是吞吐量(throughput):

于一通信通道上单位时间能成功传递的平均资料量叫做系统吞吐量。用来反映系统承压能力的指标,现在通常被人用来形容系统的QPS指标。

什么是响应时间(RT Response time):

也叫系统时延,即系统(服务端)在接受客户端请求后,经过一些列逻辑或链路处理后再返回结果,整个过程所花费的时间。该指标用来反映服务端处理速度有多快的。如下图为,向系统增加一条订单的响应时间为:T2-T1(取前后两个时刻的差值)。

提交一条订单的时间消耗

什么是在线用户数:

只登陆到系统(建立连接),但是不一定发起客户端请求的用户。严格来说系统(服务端)的压力跟在线用户数没有直接的因果关系,而是跟并发数正相关,而在线用户数跟并发数存在一定比例的转换关系,简称并发度,具体并发度的多少跟具体的业务场景相关(比如10%,20%等)。而一个系统(服务端)能够允许多少在线用户数,跟服务端的设置有关,比如设置服务端允许的最大连接数等。如图中的小人则为系统的在线用户总数,其中蓝色小人为已经发起客户端请求的用户,而绿色小人则只是建立连接,还未发起请求的用户。

在线用户数图解

什么是并发数:

上面提到并发数(也叫并发用户数)是通过在线用户数乘以并发度转换而来。其中并发可以分为绝对并发相对并发两种。绝对并发是指在某一时刻(非常短的时间内)服务端收到的请求数量。而相对并发指的是在某个时间范围内(比如:1秒钟,1分钟),服务端收到请求数量。因为绝对并发对时间点的要求非常苛刻,因此我们日常一般会用相对并发来描述一个系统的并发数量。如下图描述的是1秒时间内的并发度为16:

1秒内的并发数量

以上,是我认为对一个系统性能了解所需要掌握的几个基础概念。当然,除以上几个指标外,还有很多反映系统的名词,比如: HPS(hit per second),CPS(codes per second)等,因为不是很常用,本文将不做阐述。

04 性能指标间的关联关系

上面对性能指标的概念做了基本的阐述,那么这些指标之间有哪些是有关联关系的呢?

RPS vs TPS/PQS:

首先看客户端的发送请求能力跟服务端的处理请求能力的关系。先明确一点就是服务端的处理能力是固定的,而对于客户端而言是可以无限制扩展的(在服务端没有限定客户端连接数的情况下),它们的关系大概如下图所示:

手绘示意图

随着客户端请求量的不断增加(客户端水平扩展),服务的处理能力也随着增加。但是当请求量到达一定阈值后,服务端的处理能力渐渐趋于平缓,到最后因为受限于服务端的处理能力(一般为硬件资源受限),导致服务端负载过重,因无法承载如此大的请求量,导致系统处理能力急剧下降,甚至最后的崩溃。当然,该图反映的是一个理想状态,在实际情况中,不会有如此平滑的曲线出现,线条中一定会有很多的“毛刺”和波动出现,这才是符合正常的客观规律。

TPS/QPS vs RT vs 用户数:

随着在线用户数(并发数)的增加,响应时间会缓慢增加,同时TPS/QPS,会持续增加,但是到达某个阈值后,增量会逐渐放缓,再到后面会出现缓慢下降的趋势。同样的,该图也是描述的理想状态,实际情况中的曲线会有很多的波动。

TPS/QPS、响应时间、用户数之间的关系

以上,是我对系统性能分析的一点理解,其实涉及到系统性能方面的内容非常多,可以展开讨论的点也非常多。但是因为篇幅所限,暂时只对性能分析常用的几个指标做了简要说明。希望对你有所帮助。



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3