计算并发用户数的五种方法

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

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

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

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

    C’是并发用户数峰值

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

  那么，

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

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

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

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

  n = 170000*0.5*0.7/5 = 11900

  C= 11900*5/60/8 = 124

  吞吐量计算为：F = Vu * R / T 单位为个/s

    F为事务吞吐量，Vu为虚拟用户数个数，R为每个虚拟用户发出的请求数，T为处理这些请求所花费的时间

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

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

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

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

  246.92*3=740

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

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

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

备注：本人目前在网上只找到了这5种，计算并发用户数的方法，其他计算方法，欢迎大家留言补充

---------------------

原文：

并发用户数

并发用户数、吞吐量、思考时间的 计算公式 _1唯安EJ_新浪博客

2、并发用户数的计算公式

系统用户数：系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是2000个，那么这个数量，就是系统用户数

同时在线用户数：在一定的时间范围内，***的同时在线用户数量

平均并发用户数的计算：

C=nL / T

其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（操作平均时间），T是考察时间长度（一天内多长时间有用户使用系统）

并发用户数峰值计算：

C^ 约等于 C + 3*根号C

其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论

1000万用户可能造成的并发数量 是多少？ 解决方案（理论篇）

既然这2个公式我们来假设一下1000万用户可能会产生的并***况

1.n每天访问用户数量=1000万

2.假设这个服务是用作网上银行的操作，L=一天内用户从登陆到退出的平均时间设为（5分钟），T假设每天早晨8点-12点，均有用户访问。时长16小时即960分钟。

（这个用户数量，我们就假定为平均每天访问系统的用户数，如果是总用户数量，那么则需要先算出1000万用户，每天平均有多少用户访问。）

C=10000000*5/960=52083.33/m （即52083.33每分钟）

3.并发用户峰值为

C‘ ≈ 52083.33+3*根号52083.33=52083.33+3*228.22=52767

感觉有点奇怪的样子,也许是我的一些参数设定不合理吧,或许这些并发数量的计算不应以天为单位,而应以忙时,闲时来划分,也许更为精确.无论如何,先根据这个想法进行探索假设吧.

但是需要强调的是,我在网上找到的资料中,有些计算是以小时得出的结果,有些是以分钟得出的结果.我这里使用的是分钟计算.所以我认为,平均并发用户数应该是有一个时间作为其单位的.

当前用户并发数已满是什么意思

意思就是同时登录的用户太多了。

用户在访问或者下载某些资源的时候，同时登录的用户太多了，超过的系统可以承载的***数量，就会造成拥塞。

例如某视频资源，同一时间允许50人可以同时下载该，当该视频已有=50人在下载时，你在进入该视频下载页，点击下载，就会显示当前用户并发数已满。

当正在下载的50人当中，有人下载完成，退出下载页面之后，你就可以获取下载机会。如果需要继续下载该视频，可以暂时退出或刷新该页面，再次点击下载。

扩展资料：

解决办法：

1）通过不断的点击刷新，等待正在使用资源的用户使用完成后退出。但是如果此时有大量的人在等待使用资源，就需要保证网速足够快，在资源释放出来后，能够及时获取到机会。

2）寻找其他渠道访问资源。许多资源会采用多入口模式，如果有一个入口提示并发已满，则换一个入口进行下载。例如在下载视频资源时，A视频软件无法下载时，可以寻找另外的B视频软件、C视频软件等其他接口访问。

参考资料来源：百度百科---并发用户数

并发用户的计算

例如某系统使用用户是100个，这个就是系统用户数，该系统有一个统计查询功能，***峰在线50人，那么系统的并发数是多少？

该系统使用用户是100个，这个就是系统用户数。

***峰值50人同时在线，只表明同时登录了这个模块，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。这50人在线，有可能开着电脑溜达去了，有的看的别的模块等等。

并发用户：是同时执行一个操作的用户，或者是同时执行脚本的用户，这个并发在设置不同场景的时候并发的情况是不一样的，在实际的测试中需要根据具体的需求进行设计。web系统，在线不等于并发，如何计算这个并发数是个难题。这个就是设置集合点时候设置的在scenario-Rendezvous,点policy 设置的用户数。

估算并发数的公示：

（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

但是一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。***的并发用户数乘上一个值，2或者3.

假如说用户要求系统每秒***可以处理100个登陆请求，10/25/50/75/100 个并发用户来执行登陆操作，然后观察系统在不同负载下的响应时间和每秒事务数。如果用户数在100的时候，响应时间还在允许范围呢，就要加大用户数，例如120 等 。个人理解这个用户数就是我们经常说的等价类和边界值法来设定。

性能-什么是并发用户数

我们假设上图中的这些小人是严格按照这个逻辑到达系统的，那显然，系统的绝对并发用户数是 4。如果描述 1 秒内的并发用户数，那就是 16。是不是显而易见？

但是，在实际的系统中，用户通常是这样分配的：

也就是说，这些用户会分布在系统中不同的服务、网络等对象中。这时候”绝对并发“这个概念就难描述了，你说的是哪部分的绝对并发呢？

要说积分服务，那是 2；要说库存服务，那是 5；要说订单服务，它自己是 5 个请求正在处理，但同时它又 hold 住了 5 个到库存服务的链接，因为要等着它返回之后，再返回给前端。所以将绝对并发细分下去之后，你会发现头都大了，不知道要描述什么了。

有人说，我们可以通过 CPU 啊，I/O 啊，或者内存来描述绝对并发，来看 CPU 在同一时刻处理的任务数。如果是这样的话，绝对并发还用算吗？那肯定是 CPU 的个数呀。有人说 CPU 1ns 就可以处理好多个任务了，这里的 1ns 也是时间段呀。要说绝对的某个时刻，任务数肯定不会大于 CPU 物理个数。

所以“绝对并发”这个概念，不管是用来描述硬件细化的层面，还是用来描述业务逻辑的层面，都是没什么意义的。

我们只要描述并发就好了，不用有“相对”和“绝对”的概念，这样可以简化沟通，也不会出错。

那么如何来描述上面的并发用户数呢？在这里我建议用 TPS 来承载“并发”这个概念。

并发数是 16TPS，就是 1 秒内整个系统处理了 16 个事务。

这样描述就够了，别纠结。

那么新问题又来了，在线用户数和并发用户数应该如何算呢？下面我们接着来看示意图：

如上图所示，总共有 32 个用户进入了系统，但是绿色的用户并没有任何动作，那么显然，在线用户数是 32 个，并发用户数是 16 个，这时的并发度就是 50%。

但在一个系统中，通常都是下面这个样子的。

为了能 hold 住更多的用户，我们通常都会把一些数据放到 Redis 这样的缓存服务器中。所以在线用户数怎么算呢，如果仅从上面这种简单的图来看的话，其实就是缓存服务器能有多大，能 hold 住多少用户需要的数据。

最多再加上在超时路上的用户数。如下所示：

所以我们要是想知道在线的***的用户数是多少，对于一个设计逻辑清晰的系统来说，不用测试就可以知道，直接拿缓存的内存来算就可以了。

假设一个用户进入系统之后，需要用 10k 内存来维护一个用户的信息，那么 10G 的内存就能 hold 住 1,048,576 个用户的数据，这就是***在线用户数了。在实际的项目中，我们还会将超时放在一起来考虑。

但并发用户数不同，他们需要在系统中执行某个动作。我们要测试的重中之重，就是统计这些正在执行动作的并发用户数。

当我们统计生产环境中的在线用户数时，并发用户数也是要同时统计的。这里会涉及到一个概念：并发度。

要想计算并发用户和在线用户数之间的关系，都需要有并发度。

做性能的人都知道，我们有时会接到一个需求，那就是一定要测试出来 系统***在线用户数是多少。 这个需求怎么做呢？

很多人都是通过加思考时间（有的压力工具中叫等待时间，Sleep 时间）来保持用户与系统之间的 session 不断，但实际上的并发度非常非常低。

我曾经看到一个小伙，在一台 4C8G 的笔记本上用 LoadRunner 跑了 1 万个用户，里面的 error 疯狂上涨，当然正常的事务也有。我问他，你这个场景有什么意义，这么多错？他说，老板要一个***在线用户数。我说你这些都错了呀。他说，没事，我要的是 Running User 能达到***就行，给老板交差。我只能默默地离开了。

这里有一个比较严重的理解误区，那就是压力工具中的线程或用户数到底是不是用来描述性能表现的？我们通过一个示意图来说明：

通过这个图，我们可以看到一个简单的计算逻辑：

而我们通常说的“并发”这个词，依赖 TPS 来承载的时候，指的都是 Server 端的处理能力，并不是压力工具上的并发线程数。在上面的例子中，我们说的并发就是指服务器上 100TPS 的处理能力，而不是指 5 个压力机的并发线程数。请你切记这一点，以免沟通障碍。

所以，我一直在强调一点，这是一个基础的知识：不要在意你用的是什么压力工具，只要在意你服务端的处理能力就可以了。

上面说了这么多，我们现在来看一个实例。这个例子很简单，就是：

JMeter（1 个线程） - Nginx - Tomcat - MySQL

通过上面的逻辑，我们先来看看 JMeter 的处理情况：

我们可以看到，JMeter 的平均响应时间基本都在 5ms，因为只有一个压力机线程，所以它的 TPS 应该接近 1000ms/5ms=200TPS。从测试结果上来看，也确实是接近的。有人说为什么会少一点？因为这里算的是平均数，并且这个数据是 30s 刷新一次，用 30 秒的时间内完成的事务数除以 30s 得到的，但是如果事务还没有完成，就不会计算在内了；同时，如果在这段时间内有一两个时间长的事务，也会拉低 TPS。

那么对于服务端呢，我们来看看服务端线程的工作情况。

可以看到在服务端，我开了 5 个线程，但是服务端并没有一直干活，只有一个在干活的，其他的都处于空闲状态。

这是一种很合理的状态。但是你需要注意的是，这种合理的状态并不一定是对的性能状态。

下面我们换一下场景，在压力机上启动 10 个线程。结果如下：

平均响应时间在 25ms，我们来计算一处，(1000ms/25ms)*10=400TPS，而最新刷出来的一条是 396.2，是不是非常合理？

同样是 5 个线程，现在就忙了很多。

如果要有公式的话，这个计算公式将非常简单：

对于压力工具来说，只要不报错，我们就关心 TPS 和响应时间就可以了，因为 TPS 反应出来的是和服务器对应的处理能力，至少压力线程数是多少，并不关键。我想这时会有人能想起来 JMeter 的 BIO 和 AIO 之争吧。

你也许会说，这个我理解了，服务端有多少个线程，就可以支持多少个压力机上的并发线程。但是这取决于 TPS 有多少，如果服务端处理的快，那压力机的并发线程就可以更多一些。

这个逻辑看似很合理，但是通常服务端都是有业务逻辑的，既然有业务逻辑，显然不会比压力机快。

应该说，服务端需要更多的线程来处理压力机线程发过来的请求。所以我们用几台压力机就可以压几十台服务端的性能了。

如果在一个微服务的系统中，因为每个服务都只做一件事情，拆分得很细，我们要注意整个系统的容量水位，而不是看某一个服务的能力，这就是拉平整个系统的容量。

我曾经看一个人做压力的时候，压力工具中要使用 4000 个线程，结果给服务端的 Tomcat 上也配置了 4000 个线程，结果 Tomcat 一启动，稍微有点访问，CS 就特别高，结果导致请求没处理多少，自己倒浪费了不少 CPU。

通过示意图和示例，我描述了在线用户数、并发用户数、TPS（这里我们假设了一个用户只对应一个事务）、响应时间之间的关系。有几点需要强调：

200并发用户数是多少

200并发用户数是指同一时刻，同时服务端可以接受处理的客户端请求数。具体的数值视应用的特性和服务器的配置而定，一般情况下，200并发用户数大约可以达到500至1000之间。

并发用户数的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于一台jmeter最多设置多少并发用户数、并发用户数的信息别忘了在本站进行查找喔。