并发量计算公式

并发的基本概念

并发的概念:

  指网站在同一时间访问的人数,人数越大,瞬间带宽要求更高。

服务器并发量分为:

  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。

服务器压力计算(转载:https://www.cnblogs.com/ylcms/p/7738692.html

  你想建设一个能承受500万PV/每天的网站吗? 500万PV是什么概念?服务器每秒要处理多少个请求才能应对?如果计算呢?

PV是什么:

PV是page view的简写。PV是指页面的访问次数,每打开或刷新一次页面,就算做一个pv。

计算模型: 
每台服务器每秒处理请求的数量=((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/每天。

留足余量:

以上请求数量是均匀的分布在白天的9.6个小时中,但实际情况并不会这么均匀的分布,会有高峰有低谷。为了应对高峰时段,应该留一些余地,最少也要x2倍,x3倍也不为过。

115.7个请求/秒 *2倍=231.4个请求/秒

115.7个请求/秒 *3倍=347.1个请求/秒

23.1个请求/秒 *2倍=46.2个请求/秒

23.1个请求/秒 *3倍=69.3个请求/秒

最终结论:

如果你的服务器一秒能处理231.4--347.1个请求/秒,就可以应对平均500万PV/每天。

如果你的服务器一秒能处理46.2--69.3个请求,就可以应对平均100万PV/每天。

说明:

这里说明每秒N个请求,就是QPS。因为我关心的是应用程序处理业务的能力。

实际经验:

1、根据实际经验,采用两台常规配置的机架式服务器,配置是很常见的配置,例如一个4核CPU+4G内存+服务器SAS硬盘。

2、硬盘的性能很重要,由其是数据库服务器。一般的服务器都配1.5万转的SAS硬盘,高级一点的可以配SSD固态硬盘,性能会更好。最最最最重要的指标是“随机读写性能”而不是“顺序读写性能”。(本例还是配置最常见的1.5万转的SAS硬盘吧)

3、一台服务器跑Tomcat运行j2ee程序,一台服务器跑MySql数据库,程序写的中等水平(这个真的不好量化),是论坛类型的应用(总有回帖,不太容易做缓存,也无法静态化)。

4、以上软硬件情况下,是可以承受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带宽也不能满足要求了。你自已计算吧。

(全文完)

附:性能测试基本概念
--------------------------------------------------------------------------------------- 
基本概念: 
Throughput(吞吐量):按照常规理解网络吞吐量表示在单位时间内通过网卡数据量之和,其中即包括本机网卡发送出去的数据量也包括本机网卡接收到的数据量。 一个100Mb(位)的双工网卡,最大发送数据的速度是12.5M字节/s , 最大接收数据的速度是12.5M字节/s, 可以 同时 收发 数据。 
并发用户数:是同时执行操作的用户(线程数)。 
响应时间:从请求发出到收到响应花费的时间 。

QPS - Queries Per Second  每秒处理的查询数(如果是数据库,就相当于读取)
TPS - Transactions Per Second  每秒处理的事务数(如果是数据库,就相当于写入、修改)
IOPS,每秒磁盘进行的I/O操作次数

例如对某个数据库测试,分开两次测QPS与TPS。
QPS(读取)值总是高于TPS(写、改),并且有倍率关系,因为:
1、数据库对查询可能有缓存。
2、机械硬盘或SSD硬盘的读就是比写快。 
--------------------------------------------------------------------------------------- 
JMeter测试参数说明:

Label:每一个测试单元的名字。

#Samples:表示一个测试单元一共发出了多少个请求。

Average:平均响应时间——默认情况下是单个 Request 的平均响应时间,当使用了 Transaction Controller 时,也可以以Transaction 为单位显示平均响应时间。,不重要。

Median:中位数,也就是 50% 用户的响应时间,如果把响应时间从小到大顺序排序,那么50%的请求的响应时间在这个范围之内。重要。

90% Line:90% 用户的响应时间,如果把响应时间从小到大顺序排序,那么90%的请求的响应时间在这个范围之内。重要 。

Min:最小响应时间,不重要。

Max:最大响应时间,出现几率只不过是千分之一甚至万分之一,不重要。

Error%:本次测试中出现错误的请求的数量

Throughput:吞吐量——默认情况下表示每秒完成的请求数(Request per Second),当使用了 Transaction Controller 时,也可以表示类似 LoadRunner 的 Transaction per Second 数

KB/Sec:每秒从服务器端接收 到的数据量(只是接收),相当于LoadRunner中的Throughput/Sec 
--------------------------------------------------------------------------------------- 
loadrunner测试参数说明:

响应时间: 取90%值,如果把响应时间从小到大顺序排序,那么90%的请求的响应时间在这个范围之内。重要。

每秒点击数 :hits per Second,每秒钟向服务器提交请求的数量。

TPS: Transaction per Second ,每秒事务数,一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程

Throughput(吞吐量): Loadrunner记录的Throughput是接收到服务器返回的所有字节数之和,与本地发出的字节数无关。

Throughput/Sec: 每秒的吞吐量。

对于BS架构的一般分析 响应时间、点击率、吞吐量、TPS(每秒事务数)。 
对于CS架构的一般分析 TPS(每秒事务数)

原文地址:https://www.cnblogs.com/accumulating/p/11440739.html

时间: 2024-10-29 22:01:17

并发量计算公式的相关文章

系统吞吐量(TPS)、用户并发量、性能测试概念和公式

系统吞吐量(TPS).用户并发量.性能测试概念和公式 PS:下面是性能测试的主要概念和计算公式,记录下: 一.系统吞度量要素: 一个系统的吞度量(承压能力)与request对CPU的消耗.外部接口.IO等等紧密关联. 单个reqeust 对CPU消耗越高,外部系统接口.IO影响速度越慢,系统吞吐能力越低,反之越高. 系统吞吐量几个重要参数:QPS(TPS).并发数.响应时间 QPS(TPS):每秒钟request/事务 数量 并发数: 系统同时处理的request/事务数 响应时间:  一般取平

性能测试之QPS、TPS、并发量、系统吞吐量的概念

QPS: 每秒钟处理完请求的次数:具体是指发出请求到服务器处理完成功返回结果. TPS:每秒钟处理完的事务次数,一般TPS是对整个系统来讲的.一个应用系统1s能完成多少事务处理,一个事务在分布式处理中,可能会对应多个请求,对于衡量单个接口服务的处理能力,用QPS比较多. 并发量:系统能同时处理的请求数 RT:响应时间,处理一次请求所需要的平均处理时间 计算关系: QPS = 并发量 / 平均响应时间 并发量 = QPS * 平均响应时间 TPS: (每秒事务处理量(TransactionPerS

根据PV量来确定需要进行压测的并发量

在实际做压力测试的过程中,我们有时不知道用怎样的并发量比较好,下面是几个用PV量去确定并发量的公式,这个在我们公司是比较适用的,大家可以根据自己的业务进行运算. 方法一:这个方法是我在网上查到的80-20原则,具体运算方法为: X*0.8/(8*60*60*0.2) 说明:X为要压测页面的PV量 方法二:这个是将PV量除以高峰时段小时(比如9:00-17:00,就是8个小时),再除以60*60细化到秒,然后乘以12倍,已获得想要的并发量 (X/8/60/60)*12 说明:X为要压测页面的PV量

网站吞吐量和并发量以及响应时间的联系

吞吐量和并发量以及响应时间之间的关系可以理解为高速公路的通行状况: 吞吐量是每天通过收费站的车辆数量(可换算成收费站收取的高速费),并发量是高速公路上的正在形式的车辆数目,响应时间是车速.车辆很少的时候,车速很快,但是收到的费用也很少:随着车越来越多,车速略受影响,但是收到的高速费增加很快:随着车辆继续增加,车速越来越慢,高速公路越来越堵,收费的不增反降:如果车流量继续增加,超过某个值以后,任何偶然因素都将导致高速瘫痪,车辆走不动,费用也收不着了,而高速公路变成了停车场(资源耗尽).

针对web高并发量的处理

针对web高并发量的处理 针对高并发量的处理 一个老生常谈的话题了 至于需要运维支持的那些cdn.负载均衡神马的就不赘述了 你们都懂的 虫子在此博文只讲一些从程序角度出发的一些不错的解决方案. 至于从数据库角度的性能方案.虫子另开博文. 1. 首推静态化 推荐指数五颗星 满星五颗 只要是大型互联网应用基本上离不开这个概念,IIS自带的伪静态化不谈,但是想做好静态化并不是一个容易的过程 动态和静态之间的取舍需要用一个平衡的战略眼光来看待 举个例子 当初在盛大游戏的时候 遭遇永恒之塔aion上线,悲

处理大并发量订单处理的 KafKa部署总结

处理大并发量订单处理的 KafKa部署总结 今天要介绍的是消息中间件KafKa,应该说是一个很牛的中间件吧,背靠Apache 与很多有名的中间件搭配起来用效果更好哦 ,为什么不用RabbitMQ,因为公司需要它. 网上已经有很多怎么用和用到哪的内容,但结果很多人都倒在了入门第一步 环境都搭不起来,可谓是从了解到放弃,所以在此特记录如何在linux环境搭建,windows中配置一样,只是启动运行bat文件. 想要用它就先必须了解它能做什么及能做到什么程度,先看看它是什么吧. 当今社会各种应用系统诸

大流量高并发量网站的之解决方案

一.对于网站访问速度影响的条件如下: 瓶颈主要有: 1.磁盘搜索 优化方法是:将数据分布在多个磁盘上 2.磁盘读/写 优化方法是:从多个磁盘并行读写. 3.CPU周期 优化方法:扩充内存 4.内存带宽 二.大流量高并发量网站的解决方案 1.确认服务器硬件是否足够支持当前的流量. 2.使用memcache缓存技术,将动态数据缓存到内存中,动态网页直接调用这些文件,而不必在访问数据库. 3.禁止外部的盗链. 4.外部网站的图片或者文件盗链往往会带来大量的负载压力,因此应该严格限制外部对自身图片或者文

使用gevent提高IO繁忙型wsgi服务的并发量(转)

add by zhj: 个人认为gevent还是更牛逼一些,当然,这只是我简单的分析,没有试验过.对比分析如下: 使用Tornado,启动一个进程,N个线程 使用Gevent,启动一个进程,N个协程 CPU除了执行用户代码外,就是调用调用程序进行线程/协程切换.而协程切换要比线程切换的开销小,速度快,所以Gevent的并发性能应该更好. 原文:https://co-ding.com/?p=356#comment-6036 我的一个线上web服务在生产中遇到一个性能问题:当初为了方便选择了wsgi

对于小的并发量,我们能做的一些简单的优化,特别实际

其实很多时候,我们在现实生活中遇到的很多并发量并没有像淘宝双十一一样,可能只有它的1%而已,不要总想着,要么你的项目并发量特别大,要么你的项目并发量基本没有. 其实在实际中,我们应该尽可能的去优化我们的系统. 这里我就只列举那些现实可用的,简单的,我们能力范围之内的.这些优化方案其实对于小的并发来说足够了. 1.CDN,这个可能实现起来需要条件,它能缓存你系统的所有静态的页面数据,注意只有那些静态的页面,CSS,JS等可以缓存,CDN能减少你从主要服务器取数据的操作.而且真的很快,其实很多时候,