高并发的Web网站需要注意的

以前经常在网上看到web网站设计需要注意事项。

但实际操作性很低，因为他们只是给了一个结论，如果自己稍微有点想法，就很难去相信这些结论。

出于眼见为实的目的，正好在一个项目里，我们需要对项目做大压力并发测试。。。

1、ab只能是初步的做初步的压力测试。

很简单的道理。。我们用ab能压到最高5万的并发请求。服务器也没啥事。但是，这是真的吗？

于是我们开始监控服务器的各项资源。发现仅仅是CPU和进程有了变化。其他的IO和网络指标占用极其低下。换句话说，AB仅仅只是对服务端做了请求。html等元素并没有在ab性能测试里面。

2、网络流量是最大的瓶颈

这个网上很多人都说了。。我还是动手验证了一下。

100M带宽下，最高理论峰值是12.5M。实际峰值只有11M左右。偶尔能上12.5M。这是服务器监控的结论。客户端网络压根就没满（我用了5台客户机）。为什么会这样？简单做了一个小测试。不压任何东西。就压一个单独的图片。70k左右。200用户的时候网络出现峰值11.5M。这是什么情况呢？再看看每秒事务数，160次/s.正好11M左右。也就是说100M带宽。你的服务器同时只能传输出160张图片。这个就很容易类比了。如果你的页面需要70K的资源（html，图片，等等）。在百兆环境下，只能有160个人的并发能力。这不是服务器限制的。。网络的限制非常大。不要以为160并发很小了。按现在测试中的公式。160并发。大概等于2000人同时在线的情况。这个同时在线，是指每个人手抽经不停的点链接。。所以，在高并发的需求下，尽可能的降低页面大小。确实能够带来更多的并发处理能力。

举个例子。。gzip开启能减少50%以上的网络传输量。虽然带来cpu的负载过多。但是，在32核的服务器下，这都是浮云。但是假设是在100M带宽下，就能多带来一半的并发用户。1000M就更多了。。如果再加上千兆分流等其他手段。服务器的并发能力就能得到最大的发挥。

但如果不注意这些。我们测试了很多场景，发现网络流量始终是最大的瓶颈，压根就别想把服务器的最大处理能力发挥出来。

3、图片和附件从应用服务器分离出来是个好主意

这个的理由同上，网络流量有瓶颈，并且图片和附件是有IO的。放在应用服务器里面，影响应用服务器的处理能力。

4、应用中有影响，但不会是最大的影响

我们是用的php，但我们发现就算你代码再烂。最多耗点内存和cpu。实际的并发处理能力并不会有太大的影响。如果加入文件缓存。会有很大的io损耗，可是如果图片和附件在同一台服务器上。加入文件缓存带来的效率提升并不明显。当然，这些都是建立在高并发的情况下。

有一种缓存的处理方式，就是把缓存和内存做个映射。这样就降低了IO损耗。带来很好的效率提升。

优化数据库查询会好很多。。。。这个。因为我们的测试脚本中数据库查询本来就是最优的。。没啥可以测得。所以暂不做评价

 

 

先这么多了。。这个测试过程还在进行中。以后再补充