做性能测试并发是多少（并发性能测试的概念）

本篇文章给大家谈谈做性能测试并发是多少，以及并发性能测试的概念对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享做性能测试并发是多少的知识，其中也会对并发性能测试的概念进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、性能测试 之并发用户数知多少
• 2、网站性能测试时负载并发数怎么计算？
• 3、关于性能测试中“并发”的解释
• 4、性能测试时要求20并发，应用的并发数设置成多少合适

性能测试 之并发用户数知多少

一、经典公式1：
一般来说，利用以下经验公式进行估算系统的平均并发用户数和峰值数据

1）平均并发用户数为 C = nL/T

2）并发用户数峰值 C‘ = C + 3*根号C

C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度

C’是并发用户数峰值

举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。

那么，

平均并发用户数为：C = 400*4/8 = 200

并发用户数峰值为：C‘ = 200 + 3*根号200 = 243

举例2， 某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会用这个系统，假设只有50%的人会定期用该系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。

则一个月最后一周的平均并发用户数为（朝九晚五）：

n = 170000*0.5*0.7/5 = 11900

C= 11900*5/60/8 = 124

二、通用公式2：

对绝大多数场景，我们用（用户总量/统计时间）*影响因子（一般为3）来进行估算并发量。

比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为50000*80%/（3*60*60）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大！

三、根据PV计算公式：

比如一个网站，每天的PV大概1000w，根据2/8原则，我们可以认为这1000w pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS为：

1000w*80%/(9*3600)=246.92个/s,取经验因子3，则并发量应为：

246.92*3=740

四、根据TPS估计：

公式为 C = (Think time + 1)*TPS

五、根据系统用户数计算：

并发用户数 = 系统最大在线用户数的8%到12%

网站性能测试时负载并发数怎么计算？

这个其实没有固定的算法，必须根据压测的目标特点进行估算。
以你的例子来说明：
要求支持5000-10000用户访问的购物网站，是在同一时间访问？还是一天的访问量呢？如果是一天的访问量，那么我们需要知道哪几个时间段访问人数最多。例如有10小时访问密集区，我们可以估算每小时1000用户，峰值*2或者3，也就是每小时3000，那么合计一秒钟只要3000/3600 还不足1个并发。
如果是并发，那么就要测5000到10000了。
实际上你这是用客户视角来思考问题的，建议你采用服务器视角。
也就是说，你只管加压，看看服务器到多少并发达到峰值，用这种方法来指导网站程序和部署的优化，这才是最科学的。

关于性能测试中“并发”的解释

当我们在谈论“并发”时

动辄要求系统支持成百上千并发的性能需求太多了，也许系统在实际中确实存在这样的需求，但能够较全面理解此需求的情况并不多。

对于并发，我过去接触了几种理解，在接触的第一种理解中，“并发”是由loadrunner中获取，即脚本中所有或部分vuser执行至集合点函数时进行停留，等待触发条件发生以后，同时执行集合点函数后的请求操作的这一个过程，为“并发”（这一个请求操作一般存在多个http请求），可惜这种“并发”是无法直接用于衡量系统性能的。而在接触的第二种理解中，“并发”的理解是相对于服务器某一个时间区间内接收的请求数，也就是每秒的点击率（loadrunner考虑到这点，也就是analysis里面的hits/s），为“并发”，这种“并发”是可以用于对系统性能状况进行量化的，但是这种测试思想只是比较片面的从性能指标的角度去衡量系统性能，不能体现出系统性能带给用户何种性能体验（这也是不少开源性能测试工具的问题）。

前一种“并发”的理解普遍获得了loadrunner初级用户的认可，后一种“并发”的理解普遍获得系统运维、开发人员的认可，在沟通中为了方便区别开来，在两种角色里面，当大家意识到并发的理解存在差异时，大家把前一种被称为“狭义上的并发”，而后一种被称为“广义上的并发”。后来，又从淘宝团队里面了解了一种定义，貌似淘宝QA把“并发”定义为一个完整的事务请求数量过程（loadrunner也考虑到这点，也就是analysis里面的Transactions per Second）。一直以来，还有一种技术范围以外对“并发”的粗略的理解被第三方测试拿来用了，那就是用户在线数中的某个百分比即并发数。

如果一个团队里面对“并发”的理解有这么多种，那么当我们在讨论性能需求的“支持并发数”时，我们究竟在讨论什么呢？

个人认为，有一部分的原因是由于loadrunner是惠普saas（软件即服务的解决方案）的一部分，所以并不是一个纯粹技术人员使用的测试工具，它同时也是一个业务人员可以相对轻易掌握的性能测试工具，因此loadrunner内很多名词解释也不能单纯从技术人员的角度从字面意义上理解。

通常来说，面对同样100笔业务交易量，普遍会认为100vuser对服务器产生的负载会比50vuser要高，但是在性能脚本能够在较快的响应时间中完成时，由于50vuser执行过程中每一个vuser都需要发生两次迭代，导致了性能场景中vuser在脚本action部分停留的时间更长，因此反而能够得到比100vuser的更高的vuser在线数，更高在线数带来的也就是更大的负载，也就是说：

同等业务量的情况下，50 线程所产生的负载完全有可能比100 线程所产生的负载要高。

为了避免发生这种问题，“并发（集合点）”的真正作用就体现出来了，通过集合点函数控制了vuser的行为相对一致，降低了初始化过程和事务前后文请求产生的时间差影响。测试工具中并发存在的真正意义也就在这里，对集合点所理解的“并发”，和现场实际用户里面同时触发的请求关系不是太大。

分析“并发”需求时的一些典型：

a) 某个业务系统里面有10000用户，但是能够访问这个系统的终端数只有1000个、或者所需测试的业务每个月上限是1000笔，那么最高在线用户数就不可能超过1000、业务量也不可能超过1000。所以，有些时候在分析性能需求的时候，去统计一个业务系统的用户数还不如去统计能够访问这个系统的终端数、甚至业务量靠谱。

b) 某个业务系统里面，各个业务模块都不一样，那么就是说完成一笔业务交易，所产生的请求数也是不一样的，例如表单新增，有的需要填写20个字段，有的只需要填写5个字段，各个表单都不一样，那么为了更接近的去模拟用户现场负载，请求数都不一样的各种业务混在一起，并发数又应该是多少呢？

为了解决这些问题，需要首先考虑“并发”的粒度，以真实的业务场景为例：

a) 把粒度控制在用户上来看，假定所有用户访问一次系统平均耗时500秒，一个业务峰值会有800用户在线，则800/500=1.6。理论上，系统的性能需求是每秒要成功处理1.6个用户的请求；

b) 把粒度控制在事务上来看，假定所有用户执行一次完整的、成功的业务操作平均需要500秒，一个业务峰值有2000笔所关注的业务需要去执行，则2000/500=4。理论上，系统的性能需求是每秒要成功处理4笔业务交易；

c) 把粒度控制在请求上来看，假定所有用户执行一次完整的、不管成功或者失败的HTTP请求操作平均需要0.08秒，一个业务峰值有28000个请求需要去完成，则28000/0.08=350000。理论上，系统的性能需求是每秒要成功处理350000个请求。

实际一点的案例看看

在下面的图表中，横轴表示了某业务系统中上午9：00至12：00的一个区间，假定期间只有A、B、C访问了该业务系统。如果用户的访问过程中发送一个请求，则在请求发生的时间中标识一个点，由图可见：

A用户的行为：早上9：00访问了业务系统，并发生了一连串的请求（多个点已经连成一条直线），再然后没有再连续的发生请求（没有再出现黑线），而是有规律的间歇请求，我们暂且猜想用户A这个时候在浏览系统中的业务数据，这确实也符合浏览行为，空白阶段可以理解为在线的浏览，并不会对服务器产生负载；

B用户的行为：早上9：00访问了业务系统，并在临近12：00访问了业务系统，发送了一连串的请求，我们猜想该用户在执行了一些业务操作，浏览所占的比例比较低；

C用户的行为：仅仅在10：30左右访问了业务系统，执行了一连串业务操作以后没有再访问系统。

那么在这里案例里面，我们已知：3用户在线。问题：并发用户最高该是多少？答案其实显而易见，并发只有2个用户，因为用户C执行的业务操作的同时只有A也在执行业务操作，B完全是不在线。

还会有人认为100用户在线就应该上100个vuser/线程么？

性能测试时要求20并发，应用的并发数设置成多少合适

性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。并发性能测试是重点并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（LoadTesting）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（StressTesting）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候，尤其是以后在生产环境中实际使用起来，用户往往会产生疑问，这套系统能不能承受大量的并发用户同时访问?这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。举例说明：电信计费软件众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生费用，然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤，但当成百上千的终端，同时执行这样的操作时，情况就大不一样了，如此众多的交易同时发生，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力，预见软件的并发承受力，这是在软件测试阶段就应该解决的问题。大多数公司企业需要支持成百上千名用户，各类应用环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。如何模拟实际情况呢?找若干台电脑和同样数目的操作人员在同一时刻进行操作，然后拿秒表记录下反应时间？这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况，这样就需要压力测试工具的辅助。测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力，就为最终用户规划整个运行环境的配置提供了有力的依据。并发性能测试前的准备工作测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。测试工具：并发性能测试是在客户端执行的黑盒测试，一般不采用手工方式，而是利用工具采用自动化方式进行。成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、BenchmarkFactory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。并发性能测试的种类与指标并发性能测试的种类取决于并发性能测试工具监控的对象，以QALoad自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、JavaScript等不同的监控对象，支持Windows和UNIX测试环境。最关键的仍然是测试过程中对监控对象的灵活应用，例如三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都采用了国产中间件，选择JavaScript监控对象，手工编写脚本，可以达到测试目的。采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。并发性能测试监控的对象不同，测试的主要指标也不相同，主要的测试指标包括交易处理性能指标和UNIX资源监控。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最小服务器响应时间；Mean：平均服务器响应时间；Max：最大服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大，偏差越大；Median：中值响应时间；90%：90%事务处理的服务器响应时间）、虚拟并发用户数。应用实例：“新华社多媒体数据库V1.0”性能测试中国软件评测中心（CSTC）根据新华社技术局提出的《多媒体数据库（一期）性能测试需求》和GB/T17544《软件包质量要求和测试》的国家标准，使用工业标准级负载测试工具对新华社使用的“新华社多媒体数据库V1.0”进行了性能测试。性能测试的目的是模拟多用户并发访问新华社多媒体数据库，执行关键检索业务，分析系统性能。性能测试的重点是针对系统并发压力负载较大的主要检索业务，进行并发测试和疲劳测试，系统采用B/S运行模式。并发测试设计了特定时间段内分别在中文库、英文库、图片库中进行单检索词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳测试案例为在中文库中并发用户数200，进行测试周期约8小时的单检索词检索。在进行并发和疲劳测试的同时，监测的测试指标包括交易处理性能以及UNIX（Linux）、Oracle、Apache资源等。测试结论：在新华社机房测试环境和内网测试环境中，100M带宽情况下，针对规定的各并发测试案例，系统能够承受并发用户数为200的负载压力，最大交易数/分钟达到78.73，运行基本稳定，但随着负载压力增大，系统性能有所衰减。系统能够承受200并发用户数持续周期约8小时的疲劳压力，基本能够稳定运行。通过对系统UNIX（Linux）、Oracle和Apache资源的监控，系统资源能够满足上述并发和疲劳性能需求，且系统硬件资源尚有较大利用余地。当并发用户数超过200时，监控到HTTP500、connect和超时错误，且Web服务器报内存溢出错误，系统应进一步提高性能，以支持更大并发用户数。建议进一步优化软件系统，充分利用硬件资源，缩短交易响应时间。疲劳强度与大数据量测试疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。疲劳强度测试可以采用工具自动化的方式进行测试，也可以手工编写程序测试，其中后者占的比例较大。一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。速度测试主要是针对关键有速度要求的业务进行手工测速度，可以在多次测试的基础上求平均值，可以和工具测得的响应时间等指标做对比分析。应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。网络应用性能分析网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，例如ApplicationExpert，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间；利用ApplicationExpert调整应用在广域网上的性能；ApplicationExpert能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。网络应用性能监控在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是NetworkVantage。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。网络预测考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可人工生成流量数据），这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。PREDICTOR提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。对于应用在服务器上性能的测试，可以采用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控，测试原理如下图。UNIX资源监控指标和描述监控指标描述平均负载系统正常状态下，最后60秒同步进程的平均个数冲突率在以太网上监测到的每秒冲突数进程/线程交换率进程和线程之间每秒交换次数CPU利用率CPU占用率（%）磁盘交换率磁盘交换速率接收包错误率接收以太网数据包时每秒错误数包输入率每秒输入的以太网数据包数目中断速率CPU每秒处理的中断数输出包错误率发送以太网数据包时每秒错误数包输入率每秒输出的以太网数据包数目读入内存页速率物理内存中每秒读入内存页的数目写出内存页速率每秒从物理内存中写到页文件中的内存页数目或者从物理内存中删掉的内存页数目内存页交换速率每秒写入内存页和从物理内存中读出页的个数进程入交换率交换区输入的进程数目进程出交换率交换区输出的进程数目系统CPU利用率系统的CPU占用率（%）用户CPU利用率用户模式下的CPU占用率（%）磁盘阻塞磁盘每秒阻塞的字节数 关于做性能测试并发是多少和并发性能测试的概念的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 做性能测试并发是多少的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于并发性能测试的概念、做性能测试并发是多少的信息别忘了在本站进行查找喔。