jmeter 并发用户数,在线用户数,平均并发 峰值并发

本文探讨了并发用户数与在线用户数的区别,指出并发用户是同一时刻向服务器发送请求的用户数,而在线用户是一定时间段内的在线数量。通常并发与在线比例为5%-20%,并通过例子说明并发用户与服务器压力的关系。同时,介绍了性能测试中的并发连接数、QPS/RPS等概念,并讨论了服务器性能测试方法,强调测试应关注业务并发用户数,给出了并发用户数的计算公式。最后,讨论了并发用户数与TPS的关系,指出衡量性能应结合TPS和并发用户数,且并发用户数的意义依赖于交易完成时间。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在线用户数与并发用户数的区别和比例关系

在线用户数:用户同时在一定时间段的在线数量

并发用户数:某一时刻同时向服务器发送请求的用户数

一般而言,我们习惯以5-20的比率来推算并发用户与在线用户之间的关系。即,并发与在线的比例约为5%-20%

比如,某网站存在注册用户数为10W人,但同时在线最多1W人,但这1W个人,可能只有500人会浏览帖子,500人会进行发帖,只有这1000个人对服务器才有交易,那我们计算并发量的时候,就可以以1000为标准!

 

============================================================

 

 昨天读完了段念写的《软件性能测试过程详解与案例剖析》一书的第一章,感觉学到了不少东西,以下将该书中的我认为是精华的一篇过来给大家一起看看:
 

        在实际的性能测试中,经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”,下面用一个实际的例子来说明它们之间的差别。

        假设有一个OA系统,该系统有2000个使用用户——这就是说,可能使用该OA系统的用户总数是2000名,这个概念就是“系统用户数”,该系统有一个“在线统计”功能(系统用一个全局变量记数所有已登录的用户),从在线统计功能中可以得到,最高峰时有500人在线(这个500就是一般所说的“同时在线人数”),那么,系统的并发用户数是多少呢?

        根据我们对业务并发用户数的定义,这500就是整个系统使用时最大的业务并发用户数。当然,500这个数值只是表明在最高峰时刻有500个用户登录了系统,并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如,在这500个“同时使用系统”的用户中,考察某一个时间点,在这个时间上,假设其中40%的用户在较有兴致地看系统公告(注意:“看”这个动作是不会对服务端产生任何负担的),20%的用户在填写复杂的表格(对用户填写的表格来说,只有在“提交”的时刻才会向服务端发送请求,填写过程是不对服务端构成压力的),20%部分用户在发呆(也就是什么也没有做),剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下,可以说,只有20%的用户真正对服务器构成了压力。因此,从上面的例子中可以看出,服务器实际承受的压力不只取决于业务并发用户数,还取决于用户的业务场景。

       在实际的性能测试工作中,测试人员一般比较关心的是业务并发用户数,也就是从业务角度关注究竟应该设置多少个并发数比较合理,因此,在后面的讨论中,也是主要针对业务并发用户数进行讨论,而且,为了方便,直接将业务并发用户数称为并发用户数。

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

        (2)  并发用户数峰值: C’ ≈ C+3根号C

         公式(1)中,C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。

        公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

实例:

        假设有一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。

则根据公式(1)和公式(2),可以得到:

               C = 400*4/8 = 200

               C’≈200+3*根号200 = 242

        ,请大家不要见笑,虽然上面写的都是很基础的东西,但是对我本人来讲,在还没有看这本书之前,这些概念我是特别模糊的。

 

 

=====================================================================

 

并发连接数、请求数、并发用户数

概念

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

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

请求数-QPS(Query Per Second)/RPS(Request Per Second)

请求数有2个缩写,可以叫QPS也可以叫RPS。单位是每秒多少请求。Query=查询,也相当于请求。请求数指的是客户端在建立完连接后,向http服务发出GET/POST/HEAD数据包,服务器返回了请求结果后有两种情况:

  • http数据包头包含Close字样,关闭本次TCP连接;
  • http数据包头包含Keep-Alive字样,本次连接不关闭,可继续通过该连接继续向http服务发送请求,用于减少TCP并发连接数。

服务器性能怎么测?

通常情况下,我们测试的是QPS,也就是每秒请求数。不过为了衡量服务器的总体性能,测试时最好一起测试并发连接数和请求数。

测试原理

  • 测试并发连接数采用每个并发1请求,多个并发进行;
  • 测试请求数采用多并发、每个并发多个请求进行,总的请求数将会=并发数*单并发请求数,需要注意的是不同的并发和单并发请求数得出来的结果会不同,因此最好测试多次取平均值。

区分请求数意义何在?

大家打开Chrome浏览器,按下F12,切换到Network选项卡,随便打开一个网页,按下F5刷新,将会看到刷刷一堆的请求。这里给出某大牛收集来的不同浏览器产生的单站点并发连接数:

浏览器HTTP 1.1HTTP 1.0
IE 6,724
IE 866
Firefox 228
Firefox 366
Safari 3, 444
Chrome 1,26?
Chrome 344
Opera 9.63,10.00alpha44

以Chrome为例,假设服务器设置的是Close(非持久连接),浏览器打开网页后,首先打开4个并发加载数据,在这些请求完成后关闭4个连接,再打开4个并发连接加载数据。也就是说,并不是这个网页有100个请求就会产生100并发,而是4个并发连接并行。假设服务器设置的是keep-alive(持久连接),浏览器打开网页后,首先打开4个并发加载数据,在这些请求完成后不关闭连接,而是继续发出请求,节约重新打开连接的时间。

主机到底能多少人在线?

看到这里相信你已经知道答案了,这个问题无解,根据网页的内容大小和单网页的请求数和服务器的配置而定,这个数据的浮动值非常大所以无法测量。因此能承诺保证多少用户在线就是坑爹的主机商!

并发用户

并发用户数量,有两种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全部用户的数量,理由是这些用户可能同时使用系统;还有一种比较接近正确的观点是把用户在线数量理解为并发用户数量。实际上,在线用户不一定会和其他用户发生并发,例如正在浏览网页的用户,对服务器是没有任何影响的。但是,用户在线数量是统计并发用户数量的主要依据之一。
并发主要是针对服务器而言,是否并发的关键是看用户操作是否对服务器产生了影响。因此,并发用户数量的正确理解为:在同一时刻与服务器进行了交互的在线用户数量。这些用户的最大特征是和服务器产生了交互,这种交互既可以是单向的传输数据,也可以是双向的传送数据。
并发用户数量的统计的方法目前还没有准确的公式,因为不同系统会有不同的并发特点。例如OA系统统计并发用户数量的经验公式为:使用系统用户数量*(5%~20%)。对于这个公式是没有必要拘泥于计算的结果,因为为了保证系统的扩展空间,测试时的并发用户数量要稍微大一些,除非是要测试系统能承载的最大并发用户数量。举例说明:如果一个OA系统的期望用户为1000个,只要测试出系统能支持200个并发用户就可以了。

 

 

===============================================================================

 

近日,Hitest在其技术博客上发表了一篇题为《并发用户数与TPS之间的关系》的文章,文章对TPS和并发用户数做了详细的解释,并针对性能测试中系统性能的衡量维度和测试策略给出了自己的建议。Hitest是阿里巴巴技术质量部提供的一款Web&移动应用安全测试SaaS化服务平台,旨在帮助开发者简单快捷地进行安全测试。

在文中,作者首先对并发用户数和TPS做了解释:

并发用户数:是指现实系统中操作业务的用户,在性能测试工具中,一般称为虚拟用户数(Virutal User)。并发用户数和注册用户数、在线用户数的概念不同,并发用户数一定会对服务器产生压力的,而在线用户数只是 ”挂” 在系统上,对服务器不产生压力,注册用户数一般指的是数据库中存在的用户数。

TPS:Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标。

作者认为现在很多从业人员在做性能测试时,都错误的认为系统能支撑的并发用户数越多,系统的性能就越好。要理解这个问题,首先需要了解TPS和并发用户数之间的关系:

TPS就是每秒事务数,但是事务是基于虚拟用户数的,假如1个虚拟用户在1秒内完成1笔事务,那么TPS明显就是1;如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务,TPS就是1000了;如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务,要想达到1000TPS,至少需要1000个用户;因此可以说1个用户可以产生1000TPS,1000个用户也可以产生1000TPS,无非是看响应时间快慢。

也就是说,在评定服务器的性能时,应该结合TPS和并发用户数,以TPS为主,并发用户数为辅来衡量系统的性能。如果必须要用并发用户数来衡量的话,需要一个前提,那就是交易在多长时间内完成,因为在系统负载不高的情况下,将思考时间(思考时间的值等于交易响应时间)加到脚本中,并发用户数基本可以增加一倍,因此用并发用户数来衡量系统的性能没太大的意义。

作者最后做了综述,他认为在性能测试时并不需要用上万的用户并发去进行测试,如果只需要保证系统处理业务时间足够快,几百个用户甚至几十个用户就可以达到目的。据他了解,很多专家做过的性能测试项目基本都没有超过5000用户并发。因此对于大型系统、业务量非常高、硬件配置足够多的情况下,5000用户并发就足够了;对于中小型系统,1000用户并发就足够了。

性能测试需要一套标准化流程及测试策略,在实际测试时我们还需要考虑其它方面的问题,比如如何模拟成千上万来自不同地区用户的访问场景、如何选用合适的测试软件。性能测试对一些小的团队来说并非易事,不过前段时间阿里云发布了性能测试服务PTS,PTS可以帮助开发者通过分布式并发压力测试,模拟指定区域和指定数量的用户同时访问,提前预知网站承载力。这就是云计算给我们带来的便利。

<think>我们正在讨论如何使用JMeter测试系统的最大并发数和最佳并发数。根据用户提供的引用,我们可以构建一个完整的测试方案。最大并发数是指系统在崩溃前能承受的最大用户数,而最佳并发数则是在满足性能要求(如响应时间、错误率)的前提下,系统能处理的最大用户数。测试步骤:1.**准备工作**:-确定测试目标:明确要测试的系统功能(如登录、查询等)。-准备测试脚本:使用JMeter录制或编写目标功能的脚本,并添加必要的监听器(如响应时间、TPS、活跃线程数等)。-准备测试环境:与生产环境一致的测试环境,包括硬件、软件、网络等。2. **配置线程组**:-使用`jp@gc -SteppingThread Group`(阶梯式线程组)或`ConcurrencyThread Group`(并发线程组)来逐步增加并发用户数。根据引用[1]和[3],我们可以设置一个逐步增加并发用户数的场景,例如:-起始并发用户数:10-然后以每秒增加1个用户的速度增加到20,并持续运行60秒-再以每秒减少5个用户的速度减少到0但是,为了找到最大并发数,我们需要持续增加并发直到系统出现性能拐点(如错误率上升或响应时间陡增)。3. **添加监听器**:- `jp@gc -Active Threads OverTime`:活跃线程数随时间变化图,用于观察并发用户数的变化[^2]。-`jp@gc- ResponseTimes OverTime`:响应时间随时间变化图,观察响应时间的变化趋势。- `jp@gc -Transactions perSecond`:每秒事务数(TPS),观察系统吞吐量。-添加聚合报告和查看结果树,用于分析错误和响应数据。4.**执行测试**:-逐步增加并发用户数,直到系统出现以下任一情况:-错误率超过阈值(如5%)-响应时间超过可接受范围(如3秒)-TPS开始下降(表明系统已经过载)此时,我们可以认为达到了系统的最大并发数。5. **分析结果找到最佳并发数**:-最佳并发数通常出现在TPS达到峰值且响应时间在可接受范围内、错误率较低的时候。-通过观察响应时间图和TPS图,找到在错误率允许的情况下,TPS最高的点对应的并发用户数即为最佳并发数。具体操作示例:使用`Stepping ThreadGroup`配置:- Thisgroupwill start:10 threads(初始线程数)-First,wait for:0 seconds- Thenstart:0threads (这里我们不立即增加,而是通过后续步骤增加)- Next, add:1 threadsevery1 seconds, usingramp-up:0seconds,then holdloadfor30 seconds.-然后继续增加:再添加1个线程每1秒,持续到线程数达到20,然后保持60秒。-之后,每1秒减少5个线程直到为0。但是,为了找到最大并发数,我们可能需要调整这个策略:持续增加并发直到系统出现性能问题。因此,我们可以设置一个较大的最大线程数(比如1000),然后以每10秒增加10个线程的速度增加,直到系统出现性能拐点。另一种方法是使用`Ultimate ThreadGroup`,可以更灵活地设置多个阶梯。6. **使用断言**:-添加响应断言,检查返回结果是否正确,以便统计错误率。7. **监控服务器资源**:-使用JMeter的PerfMon插件监控服务器CPU、内存、网络等资源使用情况,以确定系统瓶颈。8. **多次测试**:-由于系统性能可能受多种因素影响,建议多次测试取平均值。9.**确定最大并发数和最佳并发数**:-最大并发数:系统开始出现大量错误(如错误率超过5%)时的并发用户数。-最佳并发数:在错误率可接受(如<1%)且响应时间满足要求的前提下,TPS达到峰值时的并发用户数。注意事项:-测试过程中需要监控数据库连接池、中间件等资源使用情况。-测试时间应足够长,以排除缓存等临时因素影响。根据引用[2]和[3],我们可以使用以下监听器来辅助分析:-jp@gc- ActiveThreadsOver Time:观察并发用户数变化-jp@gc- ResponseTimes OverTime:观察响应时间变化- jp@gc -Transactions perSecond:观察系统吞吐量通过综合这些图表,我们可以确定系统性能拐点,从而找到最大并发数和最佳并发数。下面是一个具体的配置示例:###配置阶梯式线程组(SteppingThread Group)进行最大并发数测试1. **安装插件**:-需要安装JMeter插件管理器,然后安装`CustomThread Groups`和`3BasicGraphs`。2.**添加线程组**:-右键测试计划 ->添加->线程(用户)->jp@gc- Stepping ThreadGroup3. **配置线程组参数**:-起始线程数:10-每1秒增加1个线程,直到线程数达到20(即需要10秒增加10个线程),然后持续运行60秒。-然后每1秒减少5个线程,直到为0(即4秒减少20个线程)。-总时间:10(增加时间)+60(持续运行时间)+4(减少时间)=74秒。但是,为了找到最大并发数,我们可以设置一个更大的目标线程数(比如200),并设置递增步长,例如:-起始线程数:10-每10秒增加10个线程(这样每秒增加1个线程)-直到线程数达到200(即需要190秒增加到200个线程)-然后持续运行60秒-最后每1秒减少20个线程直到为0(需要10秒)4. **添加监听器**:-添加`jp@gc- ActiveThreadsOver Time`:观察并发用户数变化。-添加`jp@gc- ResponseTimes OverTime`:观察响应时间变化。-添加`jp@gc- TransactionsperSecond`:观察TPS变化。-添加`聚合报告`和`用表格查看结果`。5.**运行测试**:-运行测试,观察监听器图表。6. **分析结果**:-当TPS曲线开始下降或响应时间曲线开始陡增时,对应的并发用户数就是最大并发数。-最佳并发数则是响应时间在可接受范围内且TPS达到峰值时的并发用户数。注意:在测试过程中,如果系统出现大量错误,则说明已经超过最大并发数。通过这种方法,我们可以逐步加压,观察系统性能变化,从而找到最大并发数和最佳并发数。引用[1]中描述的场景是逐步增加并发用户数直到20,然后保持,最后减少。而我们要找最大并发数,则需要不断加压直到系统出现性能问题,因此需要调整线程组配置,设置更高的目标线程数。总结步骤:1.使用阶梯线程组逐步增加并发用户数(如每10秒增加10个用户)。2.通过监听器观察响应时间、TPS和错误率。3.当错误率超过阈值(如5%)或响应时间超过可接受范围时,记录此时的并发用户数作为最大并发数。4.分析在错误率较低(如<1%)的情况下,TPS达到峰值时的并发用户数,即为最佳并发数。最后,多次测试取平均值,以提高准确性。相关问题:1.如何配置JMeter的阶梯线程组进行压力测试?2.如何分析JMeter测试结果中的性能拐点?3.如何通过JMeter监听器判断系统瓶颈?</think>### 如何使用 JMeter 测试系统最大并发数和最佳并发数 #### 一、核心概念解析 1. **最大并发数** - 系统在崩溃前能承受的最大用户数 - 判断标准:错误率 > 5% 或资源耗尽(CPU>95%)[^3] 2. **最佳并发数** - 性能最优时的并发用户数 - 判断标准:响应时间 ≤ 目标值 & TPS 曲线平稳 & 错误率 < 1%[^2] #### 二、测试准备阶段 1. **环境搭建** ```bash 测试环境配置 = 生产环境配置 × 0.8 # 资源按比例缩减[^3] ``` 2. **关键监听器配置** - `jp@gc - Active Threads OverTime`:监控并发用户数变化[^2] - `jp@gc - Transactions per Second`:追踪 TPS 曲线[^2] - `jp@gc - Response Times OverTime`:记录响应时间趋势 - 聚合报告:分析错误率 #### 三、阶梯加压测试法(找最大并发数) 1. **线程组配置(参考引用[1]优化)** ```properties 起始线程数:10 每1秒增加:1个线程 目标线程数:200 # 预估上限值 达到目标后持续:300秒 # 延长稳定时间 ``` > 加压公式:$$ \text{加压速率} = \frac{\text{目标线程数} - \text{起始线程数}}{\text{加压时间}} $$ 2. **终止条件判断** - 当出现以下任一情况时停止: - 错误率 > 5% - 服务器 CPU ≥ 95% - TPS 开始下降 - 记录此时的并发用户数作为 **最大并发数** #### 四、二分法定位最佳并发数 1. **测试区间设定** ```python low = 最大并发数 × 0.3 # 下限 high = 最大并发数 × 0.7 # 上限 ``` 2. **迭代测试步骤** ```mermaid graph LR A[取 mid = (low+high)/2] --> B{执行测试} B -->|响应时间达标| C[提高low=mid+1] B -->|响应时间超限| D[降低high=mid-1] C & D --> E{low≤high?} E -->|是| A E -->|否| F[输出最佳并发数] ``` 3. **验证最佳点** - 在 `mid` 值并发下持续运行 10 分钟 - 确认指标: - 响应时间波动 < 15% - TPS 标准差 < 10% - 错误率 = 0% #### 五、结果分析方法 1. **性能拐点识别** - TPS 曲线:当斜率 $k < 0.1$ 时达到瓶颈 - 响应时间:当 $RT > 2 \times \text{基线响应时间}$ 时性能下降 2. **关键指标关联分析** | 并发数区间 | TPS 趋势 | 响应时间 | 错误率 | 结论 | |------------|----------|----------|--------|------| | 0-最佳值 | ↗ 上升 | 平稳 | 0% | 系统弹性区 | | 最佳值附近 | → 平稳 | 微增 | <1% | 最佳性能区 | | >最大并发 | ↘ 下降 | 陡增 | >5% | 崩溃前兆 | #### 六、最佳实践建议 1. **动态参数化** ```sql SELECT * FROM users WHERE id = ${__Random(1,10000)} ``` - 避免数据库缓存优化造成的假象 2. **资源监控联动** - 使用 PerfMon 插件监控: - 内存使用率 >80% 时预警 - 线程阻塞率 >30% 时终止测试 3. **多轮验证策略** - 至少进行 3 轮测试: 1. 探索性测试(找大致范围) 2. 精准定位测试 3. 稳定性验证(最佳点持续运行 1 小时) > **避坑指南**: > - 网络带宽需 ≥ 预估 TPS × 平均响应大小 × 8 > - 设置合理的思考时间(建议 3-5 秒) > - 禁用 JMeter 的 GUI 模式执行测试[^3] --- **测试流程示意图**: ``` 开始 ├─ 阶梯加压测试 → 确定最大并发数[^1] ├─ 二分法迭代 → 定位最佳并发数 ├─ 稳定性验证 → 确认性能指标 └─ 生成性能报告 ```
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值