最简单的计算方式就是根据服务器带宽与页面的大小
1.假设机房带宽为10Mbs，页面的大小为20KB（包含所有的js、css、图片）
同时并发量的理论值： 10*1024/(8*20) = 64个请求/秒
理论上1秒钟同时可以有64个请求访问页面。
注意：10Mbs是位(b)，1个字节8位，所以要除8。
2. 假设进来的人是匀速的增加，
根据”三秒定律”（页面打开速度3秒），可得出并发量在单位时间内应是192个请求；
一分钟的请求量在3840。
3.根据二八定律，即80%的访问量发生在20%的时间里
3840*24*60*0.2/0.8=1382400 人次
而发生在每天的高峰期（大约5小时）内的在线人次在110万人次，一个小时为22W人次。
4.当然以上的计算都是理论值，如每个访问者停留页面的平均时间为1分钟左右，访问者的进入和退出都是比较符合正态分布.。
如果是特殊情况服务器肯定是支撑不了这么多人的，例如同一时间有大批量的访问者进入，例如考试系统。又或者同时刷新页面。
而且在实际过程中，现在的页面都肯定超过20KB，那么对带宽的要求也就更大，还有同一个局域网访问情况也要考虑。
以笔者的实际项目来说，我的项目是考试系统。出现过2次比较极端的情况。
本考试系统，登陆的页面容量比较大，所有的js,css以及图片未优化前在400KB左右，我们就以400KB为基准，所有后面要用的文件是在首页一次性加载下来的。
我用的是2台服务器，均为10Mbs带宽。 按照上面的计算方式可得出
2台服务器单位时间内应可以处理19个请求，一天能承载的测评人次是14W左右，而发生在每天的峰值时间（大约5小时）内在线人次在11W左右。
高峰期一个小时的在线人次在2.2W左右。
第一次我们测评人数是7949人，而这些测评者主要使用的是自己的手机分散测评，测评的时间线如下
高峰期是在11点期间，而从这一个小时的日志中查到与实际的服务器数据库的写入人次是17783人次（测评系统的特点是除了极少的几个页面不参数数据库数据写入，其他都是要写入答案或者个人信息）。这一天的测评情况非常顺利，服务器没有任何压力。
第二次，总共只测了2433人，但其中有1200人左右是在局域网且同时登陆系统，第一次导致其中一台机器几乎卡死，后来查看服务器日志，发现瞬时峰值有150个请求/秒，并且我是将所有的静态资源如 JSCSS图片都存放在一台服务器中的，也导致这台服务器的带宽一直很高。为了解决这个问题，只好每隔10秒登陆200个考生，一分钟内全部登陆完毕，后面1200人同时进行测评没有任何问题。主要瓶颈就是集中登陆环节。第一次出现问题的时间是下午13点，第二次分批次登陆是17点。测评的时间线如下
而这2个时间段的测评人次分别是
和
。
可以看出，出问题的时段，与数据库交互的次数其实很少，而下午17点有近27000次的交互，由此也可以得出主要瓶颈就是集中登陆系统导致的，而实际的数据也符合上面的通过计算得出的结果。