网站并发问题探讨
2013-05-08 14:49
260 查看
以前经常在网上看到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损耗。带来很好的效率提升。
优化数据库查询会好很多。。。。这个。因为我们的测试脚本中数据库查询本来就是最优的。。没啥可以测得。所以暂不做评价
但实际操作性很低,因为他们只是给了一个结论,如果自己稍微有点想法,就很难去相信这些结论。
出于眼见为实的目的,正好在一个项目里,我们需要对项目做大压力并发测试。。。
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损耗。带来很好的效率提升。
优化数据库查询会好很多。。。。这个。因为我们的测试脚本中数据库查询本来就是最优的。。没啥可以测得。所以暂不做评价
相关文章推荐
- 大型网站的架构设计问题----大型高并发高负载网站的系统架构(转)
- 大型网站的架构设计问题―-大型高并发高负载网站的系统架构
- PHP如何解决网站大流量与高并发的问题
- 总结概括对于大数据、高并发的网站如何进行优化的问题
- PHP如何解决网站大流量与高并发的问题
- PHP如何解决网站大流量与高并发的问题
- Java处理 网站高并发问题 的优化方法
- PHP如何解决网站大流量与高并发的问题
- 解决网站使用sqlite时并发问题的一个经验
- 艾伟_转载:Web网站缓存文件并发问题解决方案
- PHP如何解决网站大流量与高并发的问题
- [置顶] 大型网站的架构设计问题----大型高并发高负载网站的系统架构
- PHP如何解决网站大流量与高并发的问题
- 并发量大的网站,下单要注意的问题
- [置顶] 大型网站的架构设计问题----大型高并发高负载网站的系统架构
- 高并发高负载网站的系统架构注意的问题
- Web网站缓存:Web网站缓存文件的并发问题解决方案
- 大型网站的架构设计问题--大型高并发高负载网站的系统架构
- [置顶] 大型网站的架构设计问题----大型高并发高负载网站的系统架构
- Web网站缓存文件并发问题解决方案