网上一搜，好多通过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%，就该做出相应的动作了，是加服务器硬件，还是系统调优。

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