专栏首页bisal的个人杂货铺如何判断应用系统性能好不好?

如何判断应用系统性能好不好?

如果有人问,这个系统的性能到底好不好?有什么指标,能够说明系统的性能?且看老杨的这篇文章《如何判断一个应用系统性能好不好?》。

在建设项目系统投入生产应用前,往往会对系统做个性能压测,一是为了验证系统的在设定的不同并发数、用户数和对应业务场景下的负载能力,是否符合系统最初的设定目标,二是做到心中有数,知晓现阶段系统上述各场景下的压测表现,为后续系统的扩展,有一个较为真实的重要参考推断依据。

提到性能测试,不得不提几个常用的性能指标:

并发用户数、响应时间、吞吐量(TPS, QPS)。

分别看一下各自的指标含义:

1. 并发数指系统可以同时承载的正常使用系统功能的用户访问数量,反应系统整体负载能力。

2. 响应时间(RT)reponse time

响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间,响应时间直接反应了系统的快慢。一般关注平均响应时间和最大响应时间。对于单机没有并发操作的应用系统而言,普遍认为响应时间是一个合理且准确的性能指标,但响应时间并不能直接反应软件的性能高低。

这里普及一个概念:

软件性能的高低实际上取决于用户对该响应时间的接受程度。如游戏毫秒级响应、编译程序的分钟级响应、和图像渲染小时级、天级响应时间不在一个数量级,不能作为软件性能好坏的绝对判断。

3. 吞吐量指系统在单位时间内处理请求的数量。一个事务是指一个客户机向服务器发送请求,然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。

吞吐量体现系统处理请求的能力,这是目前最常用的性能测试指标。

吞吐量的指标受到响应时间、服务器软硬件配置、网络状态等多方面因素影响。

1. 吞吐量越大,响应时间越长。 2. 服务器硬件配置越高,吞吐量越大。 3. 网络越差,吞吐量越小。

吞吐量常用的两个量化指标QPS(每秒查询数)、TPS(每秒事务数),另外还有HPS(每秒HTTP请求数)。

TPS和QPS的区别:

1. TPS即每秒处理事务数,包括:

a) 用户请求服务器。

b) 服务器自己的内部处理。

c) 服务器返回给用户。

单位时间内/每秒能够完成N个这三个过程,TPS就是N。

2. QPS类似TPS,但不同的是,对于一个页面的一次访问,形成一个TPS。但一次页面请求,可能产生多次的对服务器请求,服务器对这些请求QPS,会计入到一次TPS中。

再看吞吐量与并发数的关系。

吞吐量:一段时间内应用系统处理用户的请求数(以下介绍指单位时间内,也可以理解为吞吐率),这个定义考察点一般是系统本身因素。当然也可以用单位时间内流经被测系统的数据流量,一般单位为b/s,即每秒钟流经的字节数,这个定义的考察点既有系统本身因素也有网络,外设等因素,也可以理解为除客户端以外的测试环境及被测系统。

并发用户数:指同一时间点对业务功能同时操作的用户数,可以分为两种:一种是严格意义上的并发,即所有的用户在同一时刻做同一件事或操作,这时业务功能一般指同一类型的业务。另外一种并发是广义范围的并发,这种并发与前一种并发的区别是,尽管多个用户对系统发出了请求或者进行了操作,但是这些请求可以是相同的,也可以是不同的,这时业务功能可能不是同一类型的业务。

一般来说,吞吐量随系统的并发用户数的增加呈现增加趋势。并发用户数是客户端单位时间内对服务器端施加的压力,具体能不能接受并处理要看被测系统的吞吐量,而吞吐量是被测系统单位时间内处理的请求数或者说单位时间内处理的字节数。一个着重于客户端的操作,一个着重于应用系统的处理能力。

两者的计算公式注明下:

平均并发用户数的计算:C=nL / T

其中C是平均的并发用户数,n是平均每天访问用户数,L是一天内用户从登录到退出的平均时间(操作平均时间),T是考察时间长度(一天内多长时间有用户使用系统)。

吞吐量计算:当没有遇到性能瓶颈的时候,吞吐量与虚拟用户数之间存在一定的联系,可以采用以下公式计算:F=VU * R / T其中F为吞吐量,VU表示虚拟用户个数,R表示每个虚拟用户发出的请求数,T表示性能测试所用的时间。

QPS(TPS),并发访问数、响应时间它们三者之间的大致对应关系是:

QPS(TPS) = 并发数/平均响应时间

注意:

1. 这里面向的对象是指整个系统。并发数是指系统满足业务正常使用场景下的最大并发访问数量、响应时间是系统整体对单个事务或查询的平均响应时间。

2. 一个系统吞吐量通常由QPS(TPS)、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。

参考:

https://www.cnblogs.com/111testing/p/11402799.html

https://www.cnblogs.com/xiaochongc/p/11782780.html

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • filebeat占用Linux空间未释放的问题解决

    我们的一台应用服务器,操作系统是Red Hat Linux,监控报警,/opt/applog文件系统使用率超阈值,整体容量为50G,但发现实际文件容量20G,剩...

    bisal
  • 一次对linux系统无影响的python3环境搭建过程及思考

    Linux系统中默认的python版本为Python 2,而根据Python的官方邮件消息,Python 2即将于2020年终止所有的支持。简单的将Python...

    bisal
  • 【Oracle】-【体系结构-DBWR】-DBWR进程相关理解

    首先从名称上,DBWR全称是Database Writer Process,属于Oracle后台进程的一种,有的地方也叫DBWn,我想这里是出于DBWR进程个数...

    bisal
  • 华为开发者大会“太素”总结我的吐槽和亮点

    上周,T哥参加了华为首届开发者大会,吸引业界关注的目光也是每次华为大会的一大特色,据主办方统计到场参会者将近三千人,虽然这个会议相比华为HCC比有些相形见绌,但...

    人称T客
  • 一文教会你查找基因的启动子、UTR、TSS等区域以及预测转录因子结合位点

    本文授权转载自科研小助手(ID:SciRes)斜体小一号字体为生信宝典的备注或校正。

    生信宝典
  • list,tuple,set,dict汇

    py3study
  • RocketMQ学习5

    进行消息发送的过程首先会准备好路由信息,最终是由netty完成的,也即使用nettyRemotingClient来实现的。

    路行的亚洲
  • View·从 InputEvent 到 dispatchTouchEvent 源码分析(二)

    延续上一篇文章(View·InputEvent事件投递源码分析(一))得出的结论,本文接着对 View、ViewGroup 的事件派发、拦截进行源码分析。

    幺鹿
  • 二叉搜索树 (BST) 的创建以及遍历

    二叉搜索树(Binary Search Tree) : 属于二叉树,其中每个节点都含有一个可以比较的键(如需要可以在键上关联值), 且每个节点的键都大于其左子树...

    用户2434869
  • 聊聊rocketmq的retryTimesWhenSendAsyncFailed

    本文主要研究一下rocketmq的retryTimesWhenSendAsyncFailed

    codecraft

扫码关注云+社区

领取腾讯云代金券