最简单的计算方法是基于服务器带宽和页面大小
1 .假设机房带宽为10Mbs，且页面大小为20KB (包括所有js、css和图像)
等量理论值： 10*1024/(8*20 )=64请求/秒
理论上一秒钟可以同时访问64个请求的页面。
注意： 10Mbs为位(b )，1字节8位，因此除以8。
2 .假设进来的人匀速增加，
根据“3秒定律”(打开页面的速度为3秒)，可以看到并发量为每单位时间192个请求。
1分钟的请求量为3840。
3 .根据二八定律，80%的访问量发生在20%的时间
3840*24*60*0.2/0.8=1382400人
每天高峰时段(约5小时)在线人数为110万人，1小时为22W人。
4 .当然，以上计算为理论值，如果每位访问者的页面停留时间平均为1分钟左右，则访问者的进入和退出呈正态分布。
如果是特殊情况，服务器肯定支持不了这么多人。 例如，同一时间有大量访问者进来，例如考试系统。 或者同时更新页面。
另外，在实际过程中，确定当前页面超过20KB，对带宽的要求也变大，需要考虑相同的LAN访问状况。
以笔者的实际项目来说，我的项目是考试系统。 出现过两次极端情况。
本测试系统，注册的页面容量比较大，没有优化所有的js、css及图像前是400KB左右，我们以400KB为基准，将后面使用的所有文件一次加载到首页。
我用的是两台服务器。 都是10Mbs的带宽。 通过上述计算方法得到
两台服务器单位时间内可处理19个请求，每天可搭载的评价人数为14W左右，而在一天的高峰时间(约5小时)内在线发生的人数为11W左右。
高峰时间1小时的在线人数在2.2W左右。
首次评估人数为7949人，这些评估人员主要使用自己的手机进行方差评估，评估时间线如下
高峰是在11点之间，但从这1小时的日志中发现与实际服务器数据库的写入的有17783人。 (评价系统的特征是，除了极少页面的无参数数据库数据写入以外，还写入回答和个人信息)。 这一天的评估非常顺利，服务器没有任何压力。
第二次，总共只测量了2433人，其中1200人左右在局域网上，同时登录了系统。 第一次，其中一台机器几乎被堵塞了。 之后，当我查看服务器日志时，发现瞬间峰值为150个请求/秒，我把所有的静态资源，如JSCSS图片都存储在一台服务器上。 因此，该服务器的带宽也一直很高。 为了解决这个问题，每隔10秒注册200名考生，在1分钟内完成所有注册，之后的1200人同时进行评估也没有任何问题。 主要瓶颈是集中登陆环节。 第一次出现问题是在下午13点，第二次批次注册是在17点。 评估的时间线如下
这两个时间段的评价人数分别为和。
发生问题的时间段，与数据库的对话次数实际上很少，晚上17点有近27000次的对话，由此也可以看出主要瓶颈是集中登录系统造成的，实际数据也与上述计算结果一致。