性能压测时,并发压力增加,系统响应时间和吞吐量如何变化

微信扫一扫,分享到朋友圈

性能压测时,并发压力增加,系统响应时间和吞吐量如何变化

性能测试



性能测试是性能优化的前提和基础,也是性能优化结果的检查和度量标准。不同视角下的网站性能有不同的标准,也有不同的优化手段。



  • 主观视角:用户感受到的性能

  • 加载页(先文字后图片)

  • 客观视角:性能指标衡量的性能



做性能优化的时候,一方面提高性能指标,另一方面要考虑到提高用户的主观感受(可以利用异步操作)。架构师训练营不介绍主观视角



性能测试指标



  • 相应时间 RT , Response Time 用户感受到的时间(客户端视角)。应用系统从发出请求开始到收到最后响应数据所需要的时间。直观的反映了系统的快慢

  • 并发数: 系统能够同时处理请求的数目,系统的负载特性。对于网站而言,并发数即系统并发用户数,指同时提交请求的用户数目。注意与在线用户数(当前登录系统的用户数)和系统用户数(可能访问系统的总用户数)的区别。一般来说,并发数不会太大,淘宝双十一高峰并发数可能是百万级别,可能同时在线数达到亿级,用户数可能超过十亿。

  • 吞吐量: 单位时间内系统处理的请求数量,系统的处理能力。对于网站,请求数/秒,页面数/秒,访问人数/天,处理的业务数/小时

  • TPS, Transactions Per Second 每秒事务数

  • 性能计数器: 描述服务器或操作系统性能的数据指标,包括 System Load、对象与线程数、内存使用、CPU 使用、磁盘与网络 I/O 等指标。



其他常用指标:



  • RPS, Request Per Second:每秒请求数

  • CPS, Codes Per Second:HTTP 返回码每秒

  • PV, Page View:页面浏览量

  • UV, Unique Vistor:独立访问者

  • IP, Internet Protocal:独立 IP 数

  • IOPS, Input/Output Operations Per Second 磁盘



吞吐量 = ( 1000 / 响应时间 ms) × 并发数



吞吐量 Throughput 的讨论需要有时间单位,一般采用 Bytes/Second、Pages/Second 和 Request/Second 等单位。



  • Bytes/Second 和 Pages/Second 表示的吞吐量,受网络设置、服务器架构、应用服务制约

  • Request/Second 表示的吞吐量,受应用服务器和应用本身的制约



不同并发用户数场景下,即使系统具有相近的吞吐量,但是得到的系统性能瓶颈也不一样。



比如 100 个并发用户,每用户每隔 1 秒发出一个 Request 和 1000 个并发用户,每隔 10 秒发出一个 Request,两个场景有相同的吞吐量 100 Request/Second,但是两个场景所占用的资源不一样,性能拐点也肯定不一样。





性能测试方法





  • 性能测试: 以系统设计初期规划的性能指标为预期目标,对系统不断施加压力,验证系统在资源可接受范围内,是否能达到性能预期

  • 负载测试: 对系统不断增加并发请求以增加系统压力,直到系统的某项或多项性能指标达到安全临界值,如某种资源已经呈饱和状态,这时候继续对系统施加压力,系统的处理能力不但不能提高,反而会下降。

  • 压力测试: 超过安全负载的情况下,对系统继续施加压力,知道系统崩溃或不能再处理任何请求,一次获得系统最大压力承受能力。

  • 稳定性测试: 在特定硬件、软件、网络环境条件下,给系统加载一定业务压力,是系统运行较长一段时间,以此检测系统是否稳定。在生产环境,请求压力是不均匀的,呈波浪特性,因此为了更好的模拟生产环境,稳定性测试也应不均匀的对系统施加压力。





究竟部署多少台服务器(资源)比较合适?是架构师需要考虑的一个决策,找到性能、价格的平衡点。架构师要清醒的知道,决策的依据到底是什么,可能的代价是什么,是否能够承担这个责任……



  • 空闲区间: 系统并发用户数比较少,吞吐量也低,系统处于空闲状态

  • 线性增长区间: 系统整体负载不大,随着并发用户数增长,吞吐量也会随之线性增长

  • 拐点: 系统并发用户数进一步增长,系统处理能力趋于饱和,每个用户的响应时间逐渐变长;系统整体吞吐量不会随着并发用户数增长而继续线性增长。

  • 过饱和区间: 系统并发用户数继续增长,系统处理能力达到过饱和状态;如果继续增加并发用户数,最终所有用户的响应时间会变得无限长;系统整体吞吐量会降为零,系统处于被压垮的状态。



Performance Testing Methodology, Quest Soft, 2005





在 TPS 增加的过程中,响应时间一开始会处在较低的状态,也就是在 A 点之前。接着响应时间开始有些增加,直到业务可以承受的时间点 B,这时 TPS 仍然有增长的空间。再接着增加压力,达到 C 点时,达到最大 TPS。我们再接着增加压力,响应时间接着增加,但 TPS 会有下降(请注意,这里并不是必然的,有些系统在队列上处理得很好,会保持稳定的 TPS,然后多出来的请求都被友好拒绝)。最后,响应时间过长,达到了超时的程度。



——《02丨性能综述:TPS和响应时间之间是什么关系?》 性能测试实战30讲



通常从两个层面定义性能场景的需求指标:业务指标和技术指标。



所有的技术指标都是在有业务场景的前提下制定的,而技术指标和业务指标之间也要有详细的换算过程。



官能小说改编的真人版,太惹火了

上一篇

南京公交车被复兴号撞了 网友:公交乘客可以吹一辈子

下一篇

你也可能喜欢

性能压测时,并发压力增加,系统响应时间和吞吐量如何变化

长按储存图像,分享给朋友