网站架设中的服务器并发数和服务器带宽估计方法
2015-09-01 10:17
537 查看
网站的负载能力主要还是依据每日PV的量。对于并发来讲,每一个页面请求可能有很多个HTTP请求,分别用来下载html,js,css和图片等部分。同时,连接持续的时间也是一个重要的参数。一般来说,就这两个参数,再加上PV的时间分布,即一天的多少小时内产生这些PV,就可以估计网站的并发数了。计算公式如下:
PC=PV/T*C*t
其中,PC是并发数,T是观测时间,即产生PV的时间长度,比如一天中的14个小时产生了20万并发,则公式中T=14*60*60秒,PV=20万。C是单个页面请求的HTTP连接数,t是连接的持续时间,一般取一个估计用户等待连接的时长,比如用户在平均等待5秒发现网页还没打开就不耐烦了,那么这个t可以取5秒。不过由于网站的访问往往有很大的不确定性,虽然我们知道平均PV,但是偶尔可能碰到访问量井喷的时候,淘宝在搞促销的时候就经常有这个问题,京东也一样,我在豆瓣上没少见到友邻鄙视京东的服务器承压能力......嘛,我们在计算的时候就必须考虑这种极端情况带来的影响,通常要在以上公式中加入一个因数,代表极端情况。那么以上公式修改为:
PC=PV/T*C*t*f
其中f表示极端情况下PV相对于平均PV的倍数。
需要注意的是,我们的计算仅考虑了服务器只有一台的情况,或者说以上计算实际上估计的是总的并发需求,并未考虑硬件上可能存在多个服务器的情况。有些帖子里会简单的在上面的公式右边再除以服务器的个数。但本人并不赞同这种做法。因为不同服务器往往要运行不同的应用和服务,那么不同的服务器被访问的量也就不同,用这种简单平均的估算方法并不准确,尤其是在项目较大,涉及的应用较多的时候,这种计算非常不合理。更好的做法是根据具体的需求和系统的架构来对各个服务器进行估计。而这就涉及到技术架构的很多方面了,比如请求中有多少是静态页面的,多少动态页面的,多少对数据库进行读写操作的,是读还是写,缓存怎么安排,如果访问量太大,单个数据库的压力太大,做成数据库集群后又如何。访问量再扩大,现有的数据架构能否跟上,服务器硬盘的I/O性能能否跟上等,都会成为估计的问题。目前我负责的项目还处于策划阶段,所以没有办法做到如此细致。但到了项目真正实施部署并测试的时候,这些应该都会成为考虑的方向。
而带宽的估计又跟并发有关,不仅如此,带宽要求还跟网页的平均大小,图片的大小有很大的关系。技术方面,缓存的方案也会大大影响带宽的使用。在不考虑任何优化的情况下,带宽的估算可以依据以下公式:
BW=PS*PC*8bit/byte*r/t
其中BW为带宽大小,PS为页面平均大小,PC为并发数,8bit/byte是单位转换,1byte=8bit,r是因数,代表极端情况,作用跟并发估计中的f因数差不多。t指用户能忍受的平均最大等待时间,比如20秒之内网页没有完全打开,用户就会离开,则t取20秒。同样,这个公式估计的也是单个服务器的带宽需求,或者是网站的总带宽需求。对于具体的情况,我们往往也要根据系统架构来对单个服务器进行估计。这里面需要考虑的因素包括网络请求中的数据平均大小,是网页则是网页的大小,是图片则是图片的大小,是Web服务接口则是通信的消息大小;浏览器端的缓存使用,js,css,图片是否放在CDN上等等。因为信息太少,我依然无法准确估计。
另外,以上计算的公式,我都是在网上看来的,没有过多的去深究机理,有什么不对的,还请高手们拍砖。
PC=PV/T*C*t
其中,PC是并发数,T是观测时间,即产生PV的时间长度,比如一天中的14个小时产生了20万并发,则公式中T=14*60*60秒,PV=20万。C是单个页面请求的HTTP连接数,t是连接的持续时间,一般取一个估计用户等待连接的时长,比如用户在平均等待5秒发现网页还没打开就不耐烦了,那么这个t可以取5秒。不过由于网站的访问往往有很大的不确定性,虽然我们知道平均PV,但是偶尔可能碰到访问量井喷的时候,淘宝在搞促销的时候就经常有这个问题,京东也一样,我在豆瓣上没少见到友邻鄙视京东的服务器承压能力......嘛,我们在计算的时候就必须考虑这种极端情况带来的影响,通常要在以上公式中加入一个因数,代表极端情况。那么以上公式修改为:
PC=PV/T*C*t*f
其中f表示极端情况下PV相对于平均PV的倍数。
需要注意的是,我们的计算仅考虑了服务器只有一台的情况,或者说以上计算实际上估计的是总的并发需求,并未考虑硬件上可能存在多个服务器的情况。有些帖子里会简单的在上面的公式右边再除以服务器的个数。但本人并不赞同这种做法。因为不同服务器往往要运行不同的应用和服务,那么不同的服务器被访问的量也就不同,用这种简单平均的估算方法并不准确,尤其是在项目较大,涉及的应用较多的时候,这种计算非常不合理。更好的做法是根据具体的需求和系统的架构来对各个服务器进行估计。而这就涉及到技术架构的很多方面了,比如请求中有多少是静态页面的,多少动态页面的,多少对数据库进行读写操作的,是读还是写,缓存怎么安排,如果访问量太大,单个数据库的压力太大,做成数据库集群后又如何。访问量再扩大,现有的数据架构能否跟上,服务器硬盘的I/O性能能否跟上等,都会成为估计的问题。目前我负责的项目还处于策划阶段,所以没有办法做到如此细致。但到了项目真正实施部署并测试的时候,这些应该都会成为考虑的方向。
而带宽的估计又跟并发有关,不仅如此,带宽要求还跟网页的平均大小,图片的大小有很大的关系。技术方面,缓存的方案也会大大影响带宽的使用。在不考虑任何优化的情况下,带宽的估算可以依据以下公式:
BW=PS*PC*8bit/byte*r/t
其中BW为带宽大小,PS为页面平均大小,PC为并发数,8bit/byte是单位转换,1byte=8bit,r是因数,代表极端情况,作用跟并发估计中的f因数差不多。t指用户能忍受的平均最大等待时间,比如20秒之内网页没有完全打开,用户就会离开,则t取20秒。同样,这个公式估计的也是单个服务器的带宽需求,或者是网站的总带宽需求。对于具体的情况,我们往往也要根据系统架构来对单个服务器进行估计。这里面需要考虑的因素包括网络请求中的数据平均大小,是网页则是网页的大小,是图片则是图片的大小,是Web服务接口则是通信的消息大小;浏览器端的缓存使用,js,css,图片是否放在CDN上等等。因为信息太少,我依然无法准确估计。
另外,以上计算的公式,我都是在网上看来的,没有过多的去深究机理,有什么不对的,还请高手们拍砖。
相关文章推荐
- 12 个免费在线的 Web 网站性能测试工具
- 亿级商品详情页架构演进技术解密 | 高可用架构系列 二
- C# 启动控制台直接打开一个网站
- 亿级商品详情页架构演进技术解密 | 高可用架构系列
- windows下nodejs express安装及入门网站,视频资料,开源项目介绍
- 简介分布式计算系统的硬件架构
- 简介分布式计算系统的硬件架构
- 可伸缩性架构分析
- 微博 Feed 架构
- 如何通过外网访问局域网地址
- 简述节点流和处理流的区别,以及Java流式输入输出的架构特点
- 浅谈iOS中MVVM的架构设计与团队协作
- 49个权威的网上学习资源网站
- Netty 架构
- 网站盗链
- 好用的在线工具类网站
- 从学习到接单赚钱 十大网络技术人员推荐收藏的网站
- 大型网站图片服务器架构的演进
- 如何快速提高网站关键词排名(实战篇)
- 小组ITalk网站开发中使用到的一些技巧