通过PV计算并发(打假,打假)

网上一搜,好多通过PV来计算并发的逻辑,乍一看很合理,仔细分析,有漏洞,总结如下:

1、网站访问量的两个概念

  网站访问量的常用衡量标准:独立访客(UV) 和 综合浏览量(PV),一般以日为单位来衡量和计算。

  • 独立访客(UV):指一定时间范围内相同访客多次访问网站,只计算为1个独立访客。比如一个用户一天多次访问网站,也只算一个UV
  • 综合浏览量(PV):指一定时间范围内页面浏览量或点击量,用户每次刷新即被计算一次。比如一个用户一天内访问了2次网站,每次访问了3个页面,就算6个PV;
       

2、并发的概念

从压测场景角度讲,压测有以下3个场景

  • 单场景压测,压测某个单一接口并发,一般15分钟
  • 混合场景压测,压测多个接口并发,一般15分钟
  • 稳定性场景压测,对整个系统进行压测,一般12小时*n,平时的话就跑一晚,假期的话就跑久一些

3、打假(一)

这里写图片描述

80~20原则:但是在现实生活中,以上两种情况发生的概率很小。根据统计学原理,采用80~20原则计算并发用户数。
8000*0.8/(8*60*60*0.2)=1.11,即每秒中有两个用户并发。

刚开始看感觉还蛮有意思,但是这算出来的是每秒钟用户访问系统页面的数量,系统有那么多页面呢,你要不要除以页面数计算出平均一个页面的并发数?一个页面也很多功能呢?再除以功能数?一个功能也许会发多个HTTP请求?还要乘以请求数?扯淡,太扯淡了,通过PV根本就算不出你压测的目标。至少算不出你单场景(某个接口)的目标并发用户数。

4、打假(二)

具体的计算公式是:并发连接数 = PV / 统计时间 * 页面衍生连接次数 * http响应时间 * 因数 / web服务器数量; 解释:
页面衍生连接次数: 一个页面请求,会有好几次http连接,如外部的css, js,图片等,这个根据实际情况而定。 http响应时间:
平均一个http请求的响应时间,可以使用1秒或更少。 因数: 峰值流量 和平均流量的倍数,一般使用5 ,最好根据实际情况计算后得出。

例子: 10PV的并发连接数: (100000PV / 86400秒 * 50个派生连接数 * 1秒内响应 * 5倍峰值) /
1台Web服务器 = 289 并发连接数

这个大牛还给了页面衍生连接数(每个页面相同吗?你每个页面都统计一下?累死你,再说了,页面衍生再多,跟我压测的接口有毛关系,50个人同时访问登录接口,登录接口可能会请求一些图片,css,这些请求我关心吗?我的并发是50*n个页面衍生请求吗?乘个屁,这个时候我登录接口的并发就是50),http响应时间(使用1秒,这不扯淡吗,不同的http请求响应时间差距大了),因数一般使用5(怎么来的,想出来的啊,我擦)

5、那怎么规划并发

经常有人QQ上问我,领导让我测试性能,我该压测多少并发;首先这种说法就不对,并发和响应时间是一起出现的。2s的响应时间支持的并发和10s响应时间支持的并发能一样吗?

谁让你测并发,你先问他,在小于多少响应时间的前提下,测试最大并发用户数;

回过头来再说,领导就是一句话,测并发,其实领导的意思是,你在X秒的响应时间前提下,测出来系统支持的最大并发用户数是多少,把这个丢给领导就行了。

领导一句话,测性能。那你就更单纯点,测下系统某功能最大TPS吧,比并发和响应时间客观一些。

结论是什么?我找不到通过PV能够计算出来并发的途径。但是系统上线后,随着业务的发展,用户的增多,并发的增加,系统有可能会崩溃对吧。这种锅你想背吗?不想,怎么避免?监控,通过监控服务器各项指标(CPU、Memory等),设定阈值,比如CPU超过50%,就该做出相应的动作了,是加服务器硬件,还是系统调优。

这是目前水平的认知,欢迎你来打我的假。
 

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页