服务器并发数怎么算（服务器并发量计算公式）

今天给各位分享服务器并发数怎么算的知识，其中也会对服务器并发量计算公式进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、IIS或apache并发连接数是怎么算的
• 2、什么是并发数？
• 3、一台应用服务器怎么计算其并发量
• 4、性能-什么是并发用户数

IIS或apache并发连接数是怎么算的

计算模型： 

每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量 。

其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用，白天请求多，晚上请求少）。 简单计算的结果：

((80%*500万)/(24小时*60分*60秒*40%))/1 = 115.7个请求/秒 

((80%*100万)/(24小时*60分*60秒*40%))/1 = 23.1个请求/秒

现在我们在做压力测试时，就有了标准，如果你的服务器一秒能处理115.7个请求，就可以承受500万PV/每天。如果你的服务器一秒能处理23.1个请求，就可以承受100万PV/每天

有人说以上条件我都满足了，但实际性能还是达不到目标。这时请注意你对外的网络的带宽，在国内服务器便宜但带宽很贵，很可能你在机房是与大家共享一条100M的光纤，实际每个人可分到2M左右带宽。再好一点5M,再好一点双线机房10M独享，这已经很贵了（北京价格）。

一天总流量：每个页面20k字节*100万个页面/1024=19531M字节=19G字节，

19531M/9.6小时=2034M/小时=578K字节/s   如果请求是均匀分布的，需要5M（640K字节）带宽（5Mb=640KB

注意大小写，b是位，B是字节，差了8倍），但所有请求不可能是均匀分布的，当有高峰时5M带宽一定不够，X2倍就是10M带宽。10M带宽基本可以满足要求。

以上是假设每个页面20k字节，基本不包含图片，要是包含图片就更大了，10M带宽也不能满足要求了。

具体设置：

第一步：启用MPM模块配置文件

我们需要在httpd.conf文件中启用该配置文件，如下所示：

# Server-pool management (MPM

specific)Include conf/extra/httpd-mpm.conf (去掉该行前面的注释符号"#")

第二步：启用MPM模块后找到配置文件进行编辑。

在Apace安装c:\ chaodiquan.com \conf\extra目录中有一个名为httpd-mpm.conf的配置文件。该文件主要用于进行MPM模块的相关配置。不过，在默认情况下，Apache的MPM模块配置文件并没有启用。

第三步：此时，我们就需要根据当前Apache服务器所使用的MPM模块，来修改对应节点下的参数配置。首先，我们来看看mpm_winnt模块下的默认配置：

#由于mpm_winnt模块只会创建1个子进程，因此这里对单个子进程的参数设置就相当于对整个Apache的参数设置。

ThreadsPerChild    150 #推荐设置：小型网站=1000 中型网站=1000~2000

大型网站=2000~3500MaxRequestsPerChild   0 #推荐设置：小=10000 中或大=20000~100000

对应的配置参数作用如下：ThreadsPerChild

每个子进程的最大并发线程数。

MaxRequestsPerChild

每个子进程允许处理的请求总数。如果累计处理的请求数超过该值，该子进程将会结束(然后根据需要确定是否创建新的子进程)，该值设为0表示不限制请求总数(子进程永不结束)。

该参数建议设为非零的值，可以带来以下两个好处：

可以防止程序中可能存在的内存泄漏无限进行下去，从而耗尽内存。

给进程一个有限寿命，从而有助于当服务器负载减轻的时候减少活动进程的数量。

什么是并发数？

并发数，计算机网络术语，是指同时访问服务器站点的连接数。

由于虚拟主机是建立在每台服务器多用户的基础上的，也就是多个用户共同使用一台服务器。为了避免同一台服务器上的某一个用户的IIS链接人数过多或占用服务器资源过多而影响其它用户的正常使用。

所以，目前所有虚拟空间提供商都对单个用户的IIS链接数，流量及服务器进程占用CPU的比率进行了相应的限制。 当某一个用户的站点超出了服务器上的设制后，访问站点时就会出现服务器忙，或目前访问该站点的人数过多，超出了WEB的处理能力等相关错误提示。

扩展资料：

并发连接数是衡量防火墙性能的一个重要指标。在市面上常见防火墙设备的说明书中大家可以看到，从低端设备的500、1000个并发连接，一直到高端设备的数万、数十万并发连接，存在着好几个数量级的差异。

在我们用电脑工作时，打开的一个窗口或一个Web页面，我们也可以把它叫做一个“会话”，扩展到一个局域网里面，所有用户要通过防火墙上网，要打开很多个窗口或Web页面发（即会话），那么，这个防火墙，所能处理的最大会话数量，就是“并发连接数”。

检查您的网站是否存在比较大的图片、FLASH、音乐、电影等文件，例如：某一个站点的访问用户并不是很多，IIS链接数也可能只有几十个，但是他在网页中使用了比较大的的FLASH或图片（如超过300K），以增强网页效果。

结果就可能会出现不能访问的情况，原因是该站点的流量（带宽）使用量超限，所以建议网页上尽量使用较小的文件，这样即能避免流量超限，也能增加客户端的下载速度，给客户更好的感觉！

最后请注意：服务器对于某一个链接的默认超时时间一般为15--20分钟，也就是当访问用户访问你的网页并关闭后，一般需要15--20分钟，服务器才从其内存中将其清除，视为无效链接！

参考资料来源：百度百科——并发数

一台应用服务器怎么计算其并发量

并发的意思是指网站在同一时间访问的人数，人数越大，瞬间带宽要求更高。服务器并发量分为：1.业务并发用户数；2.最大并发访问数；3.系统用户数；4.同时在线用户数；

说明服务器实际压力，能承受的最大并发访问数，既取决于业务并发用户数，还取决于用户的业务场景，这些可以通过对服务器日志的分析得到。

一般只需要分析出典型业务（用户常用，最关注的业务操作）

给出一个估算业务并发用户数的公式（测试人员一般只关心业务并发用户数）

C=nL/T

C^=C+3×(C的平方根)

C是平均的业务并发用户数、n是login session的数量、L是login session的平均长度、T是指考察的时间段长度、C^是指业务并发用户数的峰值。

假设OA系统有1000用户，每天400个用户发访问，每个登录到退出平均时间2小时，在1天时间内用户只在8小时内使用该系统。

C=400×2/8=100

C^=100+3×(100的平方根)=100+3×10=130

另外，如果知道平均每个用户发出的请求数u，则系统吞吐量可以估算为u×C

精确估算，还要考虑用户业务操作存在一定的时间集中性（比如上班后1小时内是OA系统高峰期），采用公式计算仍然会存在偏差。

285-104-1346

性能-什么是并发用户数

我们假设上图中的这些小人是严格按照这个逻辑到达系统的，那显然，系统的绝对并发用户数是 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（这里我们假设了一个用户只对应一个事务）、响应时间之间的关系。有几点需要强调：

服务器并发数怎么算的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于服务器并发量计算公式、服务器并发数怎么算的信息别忘了在本站进行查找喔。