关于并发用户数的思考-通过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秒，就是指每天的工作时间折成秒
峰值QPS/QPS/PV/UV/服务器数量／并发数／吐吞量／响应时间计算公式
QPS:
每秒查询率(Query Per Second) ,每秒的响应请求数，也即是最大吞吐能力。
QPS = req/sec = 请求数/秒
QPS统计方式 [一般使用 http_load 进行统计]
QPS = 总请求数 / ( 进程总数 * 请求时间 )
QPS: 单个进程每秒请求服务器的成功次数
峰值QPS:
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
PV:
访问量即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次
单台服务器每天PV计算
公式1：每天总PV = QPS * 3600 * 6
公式2：每天总PV = QPS * 3600 * 8
UV:
独立访客即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次
服务器数量：
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
机器：ceil( 每天总PV / 单台服务器每天总PV )
并发数：
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量
吐吞量：
吞吐量是指系统在单位时间内处理请求的数量
响应时间（RT):
响应时间是指系统对请求作出响应的时间
例子：
每天300w PV 的在单台机器上，这台机器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
如果一台机器的QPS是58，需要几台机器来支持？
答：139 / 58 = 3