并发量计算

1.业务并发用户数;2.最大并发访问数;3.系统用户数;4.同时在线用户数;
假设一个OA系统有1000用户,这是系统用户数;最高峰同时有500人在线,是“同时在线人数”,也称作“最大业务并发用户数”;500个同时使用系统用户中20%查看系统公告,不构成压力;20%填写表格(只在提交时才会请求,填写对服务器不构成压力);40%在发呆(什么都没做);20%用户不停从一个页面跳转另一个页面(只有这20%对服务器产生了压力)。
说明服务器实际压力,能承受的最大并发访问数,既取决于业务并发用户数,还取决于用户的业务场景,这些可以通过对服务器日志的分析得到。
一般只需要分析出典型业务(用户常用,最关注的业务操作)
给出一个估算业务并发用户数的公式(测试人员一般只关心业务并发用户数)
C=nL/T 
C^=C+3×(C的平方根)
C是平均的业务并发用户数、n是login
session的数量、L是login
session的平均长度、T是指考察的时间段长度、C^是指业务并发用户数的峰值。
该公式的得出是假设用户的login
session产生符合泊松分布而估算得到。

假设OA系统有1000用户,每天400个用户发访问,每个登录到退出平均时间2小时,在1天时间内用户只在8小时内使用该系统。
C=400×2/8=100
C^=100+3×(100的平方根)=100+3×10=130
另外,如果知道平均每个用户发出的请求数u,则系统吞吐量可以估算为u×C
请注意:精确估算,还要考虑用户业务操作存在一定的时间集中性(比如上班后1小时内是OA系统高峰期),采用公式计算仍然会存在偏差。针对例子OA系统可以把1小时设定为考察时间的粒度,将一天8小时划分为8个区间,这样可以解决业务操作存在集中性问题,更趋于精准,偏差更小。

时间: 2024-07-29 00:10:46

并发量计算的相关文章

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

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

针对web高并发量的处理

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

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

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

并发量计算公式

并发的基本概念 并发的概念: 指网站在同一时间访问的人数,人数越大,瞬间带宽要求更高. 服务器并发量分为: 1.业务并发用户数:2.最大并发访问数:3.系统用户数:4.同时在线用户数: 估算业务并发量的公式: C=nL/T C^=C+3×(C的平方根) 其中:C是平均的业务并发用户数.n是login session的数量.L是login session的平均长度.T是指考察的时间段长度.C^是指业务并发用户数的峰值. 例子分析 假设OA系统有1000用户,每天400个用户发访问,每个登录到退出平

根据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量

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

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

处理大并发量订单处理的 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