关于并发用户数的思考-通过PV量换算并发

首先介绍一下pv量：
PV(访问量)：即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次。
UV(独立访客)：即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户
端只被计算一次。
IP(独立IP)：即Internet Protocol,指独立IP数。00:00-24:00内相同IP地址之被计算一次。
***************************
问题：一个系统的日均pv量是8000，那么并发用户数应该是多少?

1、首先，我觉得应该考察这个系统的业务都有什么，各个之间有什么关联性。这些PV都分布在哪里业务上。
2、如果这些pv为单一业务，那么还要看用户在前台的一次操作，会对服务器端产生几个请求。因为如果网页中包含图片、js等内容，用户一次打开操作，会对服务器产生多个操作。
3、我们假设用户在前台的一次操作，仅产生一次pv。用户并发数是指多少用户同时对服务器产生访问。对此，我假设了三种访问情况：
    （1）最差情况：8000个用户同时发起请求，那么并发用户数应为8000
    （2）最好情况：8000个用户在时间上均匀地发起请求。那么并发用户数为8000/24*60*60=0.093。折合一分钟内之有5.5个请求，基本上就没有并发，只是单个执行。
    （3）80~20原则：但是在现实生活中，以上两种情况发生的概率很小。根据统计学原理，采用80~20原则计算并发用户数。
             8000*0.8/（8*60*60*0.2）=1.11，即每秒中有两个用户并发。
          可能有人会问：为什么是每秒多少个用户，不是每小时、每分钟、每毫秒？
          回答：我做一个120人并发查询的项目，响应时间最小0.047s，最大6.216s，平均0.779s。与服务器的一次业务交互，大约需要1秒钟。
         个人感觉，以小时、分钟做单位，时间跨度太长；以毫秒做单位，时间跨度又太短。综上所述，以秒为单位比较合适。
4、lr设置集合点后，每次迭代中，必须全部（或部分）请求得到回复后，才发起下次迭代。所以在迭代周期内我们只发送了一次并发请求，我们在根据80~20原则计算得出的并发用户数，还要乘以这个迭代周期。
      例如我的查询项目中，迭代周期大约为9秒，所以并发用户数为1.11*9=9.99,最终得到并发用户数为10个

个人观点，如有不妥之处，请指正

8000是并发的访问数，80~20原则是指80%的工作量会集中在20%的时间内完成，所以用户访问系统不是平均，而是集中在某一段时间内。0.8是指 取并发量的80%，0.2是指取工作时间的20%，8*60*60是指每天8小时，每小时60分，每分钟60秒，就是指每天的工作时间折成秒