「Web性能测试常用术语」

  CREATED BY JENKINSBOT

主题:介绍一些Web性能中常用术语,有些我也不是很懂,也是从网上和书中习得的。

本文的内容是集合网上博文、书籍外加个人的理解,小生不才,如有错误,望各位大牛不吝赐教。

并发和并行有什么区别?

做并发编程之前,必须首先理解什么是并发,什么是并行。http://www.vaikan.com/docs/Concurrency-is-not-Parallelism/#landing-slide

先面的这就话是关键:并发是指同时处理很多事情,而并行是指同时能完成很多事情。

并发(Concurrency)

同时执行多个任务,即同时做很多事情。将相互独立的执行过程综合到一起的编程技术。

《real world haskell》作者的解释:一个并发程序是指能同时执行通常不相关的各种任务。以一个游戏服务器为例子:它通常是有各种组件组成,每种组件都跟外部世界进行着复杂的信息交互。一个组件有可能要处理多个用户聊聊;另外一些可能要处理用户的输入,并把最新状态反馈给用户;其它的用来进行物理计算。这些都是并发处理。

并发程序并不需要多核处理器。

并行(Parallelism)

将一个任务拆分成多个部分同时执行,同时完成很多事情。同时执行(相关的)计算任务的编程技术。

《real world haskell》作者的解释:相比之下,并行程序是用来解决一个单一任务的。以一个试图预估某支股票价格在下一分钟波动情况的金融组件为例,如果想
最快速度的知道标普500中哪只股票应该卖出还是买进,你不能一个一个的计算,而是将这些所有的股票同时计算。这是并行。

并发数、吞吐量的概念最初用来衡量网络设备的性能,后来推广到服务器及业务上评估系统的整体性能。

一、网络设备的并发数、吞吐量并发数(Concurrency):

并发数:并发连接数,指网络设备所能处理的最大会话数量。这里的会话数是指“请求->响应”一次会话。

吞吐量(Throughput):用户请求是由一个个数据包组成,网络设备(防火墙/路由器/交换机)对每个数据包的处理要耗费资源。吞吐量是指在不丢包的情况下单位时间内通过网络设备的数据包数量。

网络层面,并发数和吞吐量的关系: 并发数x包长度=吞吐量

参考:吞吐与并发关系可以看出,在网络层面考察吞吐量,除了并发数,还要考虑请求包的大小(长度)。用于度量网络设备时候,可以用byte/秒。

二、服务器及业务上的并发数、吞吐量用于指网站性能/服务器性能时候:

并发/并发用户:

并发分为两种情况:1.严格意义上的并发,即所有的用户在同一时刻执行相同操作,比如同时提交订单。2.广义上的并发,即多个用户同时对服务器发起请求,但是可能访问的是不同的业务。

并发用户数量:

在同一时刻
与服务器进行了交互的在线用户数量。

与吞吐量相比,并发用户数是一个
更直观但也更笼统的性能指标。实际上,并发用户数是一个非常不准确的指标,因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。以网站系统为例,假设用户只有注册后才能使用,但注册用户并不是每时每刻都在使用该网站,因此具体一个时刻只有部分注册用户同时在线,在线用户就在浏览网站时会花很多时间阅读网站上的信息,因而具体一个时刻只有部分在线用户同时向系统发出请求。这样,对于网站系统我们会有三个关于用户数的统计数字:注册用户数、在线用户数、同时发请求用户数。由于注册用户可能长时间不登陆网站,使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言,以在线用户作为性能指标更直观些,而以同时发请求用户数作为性能指标更准确些。

请求响应时间:

从请求开始到响应结束的整个过程的时间。有些测试工具中也称为TTLB(time to last byte)

吞吐量:

在一次性能测试中网络上传输的数据量的总和。

吞吐率(Throughput):

单位时间内网络上传输的数据量的总和。吞吐率 = 吞吐量 / 传输时间

吞吐量是指系统在单位时间内处理请求的数量。只不过是一个很宽泛的术语,大家经常指的吞吐量的单位可能是:TPS/QPS、页面数/秒、人数/天、处理业务数/小时等等。

对于无并发的应用系统而言,吞吐量与响应时间成严格的反比关系,实际上此时吞吐量就是响应时间的倒数。

  • 对于单用户的系统,响应时间(或者系统响应时间和应用延迟时间)可以很好地度量系统的性能,但对于并发系统,通常需要用吞吐量作为性能指标。
  • 对于一个多用户的系统,如果只有一个用户使用时系统的平均响应时间是t,当有你n个用户使用时,每个用户看到的响应时间通常并不是n×t,而往往比n×t小很多(当然,在某些特殊情况下也可能比n×t大,甚至大很多)。这是因为在处理多个请求时,如果资源配置合理,请求是并发处理,每个用户看到的响应时间并不随用户数的增加而线性增加。实际上,不同系统的平均响应时间随用户数增加而增长的速度也不大相同,这也是采用吞吐量来度量并发系统的性能的主要原因。

一般而言,吞吐量是一个比较通用的指标,两个具有不同用户数和用户使用模式的系统,如果其最大吞吐量基本一致,则可以判断两个系统的处理能力基本一致。

TPS:Transactions Per Second(每秒事务处理数):

服务器每秒处理的事务次数。一般用于评估数据库、交易系统的基准性能。

事务响应时间:

事务由一系列请求组成,事物的响应时间主要是针对用户而言,属于宏观概念,是为了向用户说明业务的响应时间。

点击率:

每秒钟用户向Web服务器提交的HTTP请求数量。

资源利用率:

指的是对不同系统资源的使用程度。如:CPU、磁盘。

并发数

系统同时处理的请求数(分为查询类请求数、事务类请求数)。

并发连接数-SBC(Simultaneous Browser Connections)

并发连接数指的是客户端向服务器发起请求,并建立了TCP连接。每秒钟服务器连接的总TCP数量,就是并发连接数。

RT:Response Time(响应时间,也叫Think Time。)

客户端发一个请求开始计时,到客户端接收到从服务器端返回的响应结果结束所经历的时间,响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。

直观上看,这个指标与人对软件性能的主观感受是非常一致的,因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能,而不同功能的处理逻辑也千差万别,因而不同功能的响应时间也不尽相同,甚至同一功能在不同输入数据的情况下响应时间也不相同。

所以,在讨论一个系统的响应时间时,人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然,往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。

对于单机的没有并发操作的应用系统而言,人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是,响应时间的绝对值并不能直接反映软件的性能的高低,软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说,响应时间小于100毫秒应该是不错的,响应时间在1秒左右可能属于勉强可以接受,如果响应时间达到3秒就完全难以接受了。而对于编译系统来说,完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间,但这些响应时间对于用户来说都是可以接受的。

响应速度提升说明单词请求的处理速度提升,用户感觉任务处理速度更快,系统反应速度更快。当然在处理能力不变的情况下,RT的提升必然会提升QPS。

如何提升RT?

1)减少I/O的响应时间

2)减少I/O的调用次数

3)减少CPU使用时间(当然在I/O占大头的应用里,这方面优化效果肯定不明显)

QPS:Queries Per Second(查询量/秒)

服务器每秒能够处理的查询次数,例如域名服务器、MySQL查询性能。

每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,在因特网上,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec,即每秒的响应请求数,也即是最大吞吐能力。

从概念来看吞吐量和响应时间是衡量系统性能的重要指标,QPS虽然和吞吐量的计量单位不同,但应该是成正比的,任何一个指标都可以含量服务器的并行处理能力。当然Throughput更关心数据量,QPS更关心处理笔数。

QPS提升带来什么?QPS提升说明单台服务器处理能力提升,如果QPS提升1倍,服务器资源减少1半,或者说服务器不变可以支撑2倍的请求量。

如何提升QPS?
1)减少CPU的使用时间(哪些代码会消耗CPU:循环、字符串拼接\查找\替换、编码\解码、序列化\反序列化、压缩)

2)增加CPU的数量

3)减少同步锁

如果CPU不能被压到85%以上,并且此时的QPS已经达到了峰值,则说明另有瓶颈,接下去关注内存)。

RPS:Request Per Second(请求数/秒)

RPS(Request Per Second)和QPS可以认为是一回事。

并发数与TPS/QPS的关系:QPS(TPS)= 并发数/平均响应时间,这里的并发数如果为事务处理请求数,则为TPS,如果为查询请求数,则为QPS。

参考文献

知乎:https://www.zhihu.com/question/36734171/answer/68995124
CSDN: http://blog.csdn.net/yangzhenzhen/article/details/22305977
ifeve: http://ifeve.com/parallel_and_con/
vaikan: http://www.vaikan.com/defining-concurrency-and-parallelism/
《Web性能测试实战》:1.1 Web性能测试简介