性能测试新手常犯错误总结(三):用户数与压力

2024-02-01 02:08

本文主要是介绍性能测试新手常犯错误总结(三):用户数与压力,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!



    同样的项目、同样的性能需求,让不同的测试人员来测,会是相同的结果么?

  假设有这样一个小论坛,性能测试人员得到的需求是“支持并发50人,响应时间要在3秒以内”,性能测试人员A和B同时开始进行性能测试(各做各的)。


  只考虑发帖这个操作,A设计的测试场景是50人并发发帖,得到的测试结果是平均完成时间是5秒。于是他提出了这个问题,认为系统没有达到性能期望,需要开发人员进行优化。


  B设计的测试场景是,50个人在线,并且在5分钟内每人发一个帖子,也就是1分钟内有10个人发帖子,最后得到的测试结果是平均完成时间2秒。于是他的结论是系统通过性能测试,可以满足上线的压力。


  两个人得到了不同的测试结果,完全相反的测试结论,谁做错了?


  或许这个例子太极端,绝对并发和平均分布的访问压力当然是截然不同的,那我们再来看个更真实的例子。


  还是一个小论坛,需求是“100人在线时,页面响应时间要小于3秒”。A和B又同时开工了,这时他们都成长了,经验更加丰富了,也知道了要设计出更符合实际的测试场景。假设他们都确认了用户的操作流程为“登录-进入子论坛-(浏览列表-浏览帖子)×10-发帖”,即每个用户看10个帖子、发一个帖子。于是他们都录制出了同样的测试脚本。


  A认为,每个用户的操作,一般间隔30s比较合适,于是他在脚本中的每两个事务之间加上了30秒的等待(思考时间)。


  B想了想自己看论坛时的情景,好像平均每次鼠标点击要间隔1分钟,于是他在脚本中的每两个事务之间加上了1分钟的等待。


  他们都认为自己的测试场景比较接近实际情况,可惜测试结果又是不同的,很显然A场景的压力是B的两倍。那谁错了呢?或者有人说是需求不明确导致的,那么你需要什么样的需求呢?

   这里我想问几个问题,希望各位看完了上面的小例子后想一想:


  如果有另一个人和你测同样的系统,你们的测试结果会一致么?


  如果不一致,那么谁是正确的?


  如何证明测试结果是有效的?


  如果你有了一些疑惑,对之前的测试结果少了一些自信,那么请继续。

  服务器视角 vs. 用户视角


  性能测试中非常重要的一块内容就是模拟预期的压力,测试系统运行在此压力下,用户的体验是什么样的。


  那么压力是什么?压力是服务器在不断的处理事情、甚至是同时处理很多事情。压力是服务器直接处理的“事情”,而不是远在网络另一端的用户。


    下图中,每一个颜色的线段代表一种操作。在任意一个时刻,服务器都知道它有10个事务需要处理,这10个事务也是有10个用户产生的。但它不知道的是,整个时间段内的所有事务,是由多少个用户与系统交互而产生的。

  这句话好像有点绕,我再试着更形象的解释一下。时刻1,10个当前事务是由10个用户发起的。时刻2,依然是10个正在进行的事务,但可能是完全不同的10个人发起的。在这段时间内,服务器每一个时刻都在处理10个事务,但是参与了这个交互过程(对服务器产生压力)的人可能会达到上百个,也可能只有最开始的10个。


  那么,对于服务器来说,压力是什么呢?显然只是每时刻这10个同时处理的事务,而到底是有10个人还是1000个人,区别不大(暂不考虑session等问题)。


  下面再从用户的视角来看看。实际的情况中,不可能出现很多用户同一时刻开始进行操作的场景,而是有一定的时间顺序的。正如下图所示,在这个时间段内,一共有23个用户进行了操作。

  但是服务器能看到这些用户么?它知道的只是某一个时间点上,有多少个正在执行的事务。大家可以数一下,此图中任意时刻的并发事务依然是10个。


  其实这两个图描述的本来就是同一个场景,只不过观察者的视角不同罢了。


  那么大家想想,在性能需求中最常见到的“并发用户”到底是指的什么呢?


    并发用户


  很多使用“并发用户”这个词的人,并没有从服务器视角进行考虑。他们想的是坐在电脑前使用这个系统、对系统产生压力的人的个数。基于这个原因,我很少使用这个容易让人误解的词汇,而是进行了更细的划分。主要有这么几个:系统用户数(注册用户数)、在线用户数(相对并发用户数)、绝对并发用户数。

  上面几个例子中所说的“并发用户”,实际就是在线用户数。其实我更喜欢叫做相对并发用户数,因为这个词更容易让人感受到“压力”。相对并发用户数指的是,在一个时间段内,与服务器进行了交互、对服务器产生了压力的用户的数量。这个时间段,可以是一天,也可以是一个小时。而需求人员必须要描述的,也正是这个内容。


  而绝对并发用户,主要是针对某一个操作进行测试,即多个用户同一时刻发起相同请求。可以用来验证是否存在并发逻辑上的处理问题,如线程不安全、死锁等问题;也可提供一些性能上的参考信息,比如1个用户需要1秒,而10个用户并发却需要30秒,那很可能就会有问题,需要进行关注,因为10个用户请求排队处理也应该只需要10秒啊。但这种绝对并发的测试,同实际压力下的用户体验关系不大。


  再回到相对并发这个概念上来,它与服务器的压力到底是什么关系呢?如果你理解了前面的所有内容,那么就会知道这两者其实没有直接联系(当然了,同一个测试用例中,肯定是用户数越多压力越大)。也就是说,你得到的这种性能需求,是无法知道服务器到底要承受多大压力的。


  那么如何开展性能测试?


  如何模拟压力


  既然我们知道了所谓的压力其实是从服务器视角来讲的,服务器要处理的事务才是压力,那么我们就从这出发,来探寻一下性能测试需要的信息。依然用之前的小论坛为例,我们需要测试活跃用户为500人时,系统的性能是否能还能提供良好的用户感受。


  假设现在的活跃用户有50个人(或者通过另一个类似的系统来推算也行),平均每天总的发帖量是50条、浏览帖子500次,也就是每人每天发一个帖子、浏览十个帖子(为了方便讲解,假设论坛只有这两个基本功能)。那么我们就可以推算,活跃用户达到500时,每天的业务量也会成比例的增长,也就是平均每天会产生500个新帖子、浏览帖子5000次。


  进一步分析数据,又发现。用户使用论坛的时间段非常集中,基本集中在中午11点到1点和晚上18点到20点。也就是说每天的这些业务,实际是分布在4个小时中完成的。


  那我们的测试场景,就是要用500个用户在4小时内完成“每人发一个帖子、浏览十个帖子”的工作量。


  注意上面的两处,“平均每天……”、“分布在4个小时……”。敏感的测试人员应该能发现,这个场景测的是平均压力,也就是一个系统最平常一天的使用压力,我喜欢称之为日常压力。


  显然,除了日常压力,系统还会有压力更大的使用场景,比如某天发生了一件重要的事情,那么用户就会更加热烈的进行讨论。这个压力,我习惯叫做高峰期压力,需要专门设计一个测试场景。


  这个场景,需要哪些数据呢,我们依然可以从现有的数据进行分析。比如上面提到的是“平均每天总的发帖量……”,那么这次我们就要查到过去最高一日的业务量。“分布在4个小时”也需要进行相应的修改,比如查查历史分布图是否有更为集中的分布,或者用更简单通用的80-20原则,80%的工作在20%的时间内完成。根据这些数据可以再做适当的调整,设计出高峰期的测试场景。


  实际工作中可能还需要更多的测试场景,比如峰值压力场景。什么是峰值压力呢,比如一个银行网站,可能会由于发布一条重磅消息使访问量骤增,这个突发的压力也是性能测试人员需要考虑的。


  需要注意高峰期压力和峰值压力的区别,高峰期压力是指系统正常的、预期内压力的一个高峰。而峰值压力是指那些不在正常预期内的压力,可能几年才出现一次。


  这里只是举了个最简单的例子,实际工作远比这复杂的多。需要哪些数据、如何获取,很可能要取得这些数据就要花费很大的功夫。这其实就涉及到了一个很重要的内容,用户模型和压力模型的建立,以后会有专门的文章进行讲述。


  为什么要花这么大的精力来收集这些信息呢?是因为只有通过这些有效的数据,才能准确的去模拟用户场景,准确的模拟压力,获取到更加真实的用户体验。只有这样,“不同的测试人员,测出相同的结果”才会有可能实现,而且结果都是准确有效的。


  要点回顾


  ● 最后通过几个小问题来总结回顾一下:

  ● 你真的理解“并发用户”的意义么?

  ● 什么是用户视角和服务器视角?

  ● 什么是压力?

  ● 如何模拟预期压力?


这篇关于性能测试新手常犯错误总结(三):用户数与压力的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/665752

相关文章

Python如何使用__slots__实现节省内存和性能优化

《Python如何使用__slots__实现节省内存和性能优化》你有想过,一个小小的__slots__能让你的Python类内存消耗直接减半吗,没错,今天咱们要聊的就是这个让人眼前一亮的技巧,感兴趣的... 目录背景:内存吃得满满的类__slots__:你的内存管理小助手举个大概的例子:看看效果如何?1.

java常见报错及解决方案总结

《java常见报错及解决方案总结》:本文主要介绍Java编程中常见错误类型及示例,包括语法错误、空指针异常、数组下标越界、类型转换异常、文件未找到异常、除以零异常、非法线程操作异常、方法未定义异常... 目录1. 语法错误 (Syntax Errors)示例 1:解决方案:2. 空指针异常 (NullPoi

Redis中高并发读写性能的深度解析与优化

《Redis中高并发读写性能的深度解析与优化》Redis作为一款高性能的内存数据库,广泛应用于缓存、消息队列、实时统计等场景,本文将深入探讨Redis的读写并发能力,感兴趣的小伙伴可以了解下... 目录引言一、Redis 并发能力概述1.1 Redis 的读写性能1.2 影响 Redis 并发能力的因素二、

Java反转字符串的五种方法总结

《Java反转字符串的五种方法总结》:本文主要介绍五种在Java中反转字符串的方法,包括使用StringBuilder的reverse()方法、字符数组、自定义StringBuilder方法、直接... 目录前言方法一:使用StringBuilder的reverse()方法方法二:使用字符数组方法三:使用自

Golang中拼接字符串的6种方式性能对比

《Golang中拼接字符串的6种方式性能对比》golang的string类型是不可修改的,对于拼接字符串来说,本质上还是创建一个新的对象将数据放进去,主要有6种拼接方式,下面小编就来为大家详细讲讲吧... 目录拼接方式介绍性能对比测试代码测试结果源码分析golang的string类型是不可修改的,对于拼接字

Python依赖库的几种离线安装方法总结

《Python依赖库的几种离线安装方法总结》:本文主要介绍如何在Python中使用pip工具进行依赖库的安装和管理,包括如何导出和导入依赖包列表、如何下载和安装单个或多个库包及其依赖,以及如何指定... 目录前言一、如何copy一个python环境二、如何下载一个包及其依赖并安装三、如何导出requirem

mysql线上查询之前要性能调优的技巧及示例

《mysql线上查询之前要性能调优的技巧及示例》文章介绍了查询优化的几种方法,包括使用索引、避免不必要的列和行、有效的JOIN策略、子查询和派生表的优化、查询提示和优化器提示等,这些方法可以帮助提高数... 目录避免不必要的列和行使用有效的JOIN策略使用子查询和派生表时要小心使用查询提示和优化器提示其他常

Rust格式化输出方式总结

《Rust格式化输出方式总结》Rust提供了强大的格式化输出功能,通过std::fmt模块和相关的宏来实现,主要的输出宏包括println!和format!,它们支持多种格式化占位符,如{}、{:?}... 目录Rust格式化输出方式基本的格式化输出格式化占位符Format 特性总结Rust格式化输出方式

SpringBoot中整合RabbitMQ(测试+部署上线最新完整)的过程

《SpringBoot中整合RabbitMQ(测试+部署上线最新完整)的过程》本文详细介绍了如何在虚拟机和宝塔面板中安装RabbitMQ,并使用Java代码实现消息的发送和接收,通过异步通讯,可以优化... 目录一、RabbitMQ安装二、启动RabbitMQ三、javascript编写Java代码1、引入

Nginx设置连接超时并进行测试的方法步骤

《Nginx设置连接超时并进行测试的方法步骤》在高并发场景下,如果客户端与服务器的连接长时间未响应,会占用大量的系统资源,影响其他正常请求的处理效率,为了解决这个问题,可以通过设置Nginx的连接... 目录设置连接超时目的操作步骤测试连接超时测试方法:总结:设置连接超时目的设置客户端与服务器之间的连接