你想建设一个能承受500万PV/每天的网站吗?如果计算呢?

标签: 建设 pv 网站 | 发表时间:2014-09-09 07:20 | 作者:coollyj
出处:http://www.iteye.com
博客:http://elf8848.iteye.com

你想建设一个能承受500万PV/每天的网站吗? 500万PV是什么概念?服务器每秒要处理多少个请求才能应对?如果计算呢?

PV是什么:
PV是page view的简写。PV是指页面的访问次数,每打开或刷新一次页面,就算做一个pv。

计算模型:
每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量 。
其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时,有80%的请求发生一天的9.6个小时当中(很适合互联网的应用,白天请求多,晚上请求少)。

简单计算的结果:
((80%*500万)/(24小时*60分*60秒*40%))/1 = 115.7个请求/秒
((80%*100万)/(24小时*60分*60秒*40%))/1 = 23.1个请求/秒

初步结论:
现在我们在做压力测试时,就有了标准,如果你的服务器一秒能处理115.7个请求,就可以承受500万PV/每天。如果你的服务器一秒能处理23.1个请求,就可以承受100万PV/每天。

留足余量:
以上请求数量是均匀的分布在白天的9.6个小时中,但实际情况并不会这么均匀的分布,会有高峰有低谷。为了应对高峰时段,应该留一些余地,最少也要x2倍,x3倍也不为过。
115.7个请求/秒 *2倍=231.4个请求/秒
115.7个请求/秒 *3倍=347.1个请求/秒
23.1个请求/秒 *2倍=46.2个请求/秒
23.1个请求/秒 *3倍=69.3个请求/秒

最终结论:
如果你的服务器一秒能处理231.4--347.1个请求/秒,就可以应对平均500万PV/每天。
如果你的服务器一秒能处理46.2--69.3个请求,就可以应对平均100万PV/每天。

说明:
这里说明每秒N个请求,就是QPS。因为我关心的是应用程序处理业务的能力。

实际经验:
1、根据实际经验,采用两台常规配置的机架式服务器,配置是很常见的配置,例如一个4核CPU+4G内存+服务器SAS硬盘。
2、个人武断的认为在服务器CPU领域Intel的CPU要优于AMD的CPU,有反对的就反对吧,我都说我武断了(请看CPU性能比较),不要太相信AMD的广告,比较CPU性能简单办法就是比价格,不要比频率与核心数,价格相差不多的性能也相差不多。
3、硬盘的性能很重要,由其是数据库服务器。一般的服务器都配1.5万转的SAS硬盘,高级一点的可以配SSD固态硬盘,性能会更好。最最最最重要的指标是“随机读写性能”而不是“顺序读写性能”。(本例还是配置最常见的1.5万转的SAS硬盘吧)
4、一台服务器跑Tomcat运行j2ee程序,一台服务器跑MySql数据库,程序写的中等水平(这个真的不好量化),是论坛类型的应用(总有回帖,不太容易做缓存,也无法静态化)。
5、以上软硬件情况下,是可以承受100万PV/每天的。(已留有余量应对突然的访问高峰)

注意机房的网络带宽:
有人说以上条件我都满足了,但实际性能还是达不到目标。这时请注意你对外的网络的带宽,在国内服务器便宜但带宽很贵,很可能你在机房是与大家共享一条100M的光纤,实际每个人可分到2M左右带宽。再好一点5M,再好一点双线机房10M独享,这已经很贵了(北京价格)。
一天总流量:每个页面20k字节*100万个页面/1024=19531M字节=19G字节,
19531M/9.6小时=2034M/小时=578K字节/s   如果请求是均匀分布的,需要5M(640K字节)带宽(5Mb=640KB 注意大小写,b是位,B是字节,差了8倍),但所有请求不可能是均匀分布的,当有高峰时5M带宽一定不够,X2倍就是10M带宽。10M带宽基本可以满足要求。
以上是假设每个页面20k字节,基本不包含图片,要是包含图片就更大了,10M带宽也不能满足要求了。你自已计算吧。
(全文完)



附:性能测试基本概念
---------------------------------------------------------------------------------------
基本概念:
Throughput(吞吐量):按照常规理解网络吞吐量表示在单位时间内通过网卡数据量之和,其中即包括本机网卡发送出去的数据量也包括本机网卡接收到的数据量。 一个100Mb(位)的双工网卡,最大发送数据的速度是12.5M字节/s , 最大接收数据的速度是12.5M字节/s, 可以 同时 收发 数据。
并发用户数:是同时执行操作的用户(线程数)。
响应时间:从请求发出到收到响应花费的时间 。

QPS - Queries Per Second  每秒处理的查询数(如果是数据库,就相当于读取)
TPS - Transactions Per Second  每秒处理的事务数(如果是数据库,就相当于写入、修改)
IOPS,每秒磁盘进行的I/O操作次数

例如对某个数据库测试,分开两次测QPS与TPS。
QPS(读取)值总是高于TPS(写、改),并且有倍率关系,因为:
1、数据库对查询可能有缓存。
2、机械硬盘或SSD硬盘的读就是比写快。
---------------------------------------------------------------------------------------
JMeter测试参数说明:

Label:每一个测试单元的名字。

#Samples:表示一个测试单元一共发出了多少个请求。

Average:平均响应时间——默认情况下是单个 Request 的平均响应时间,当使用了 Transaction Controller 时,也可以以Transaction 为单位显示平均响应时间。,不重要。

Median:中位数,也就是 50% 用户的响应时间,如果把响应时间从小到大顺序排序,那么50%的请求的响应时间在这个范围之内。重要。

90% Line:90% 用户的响应时间,如果把响应时间从小到大顺序排序,那么90%的请求的响应时间在这个范围之内。重要 。

Min:最小响应时间,不重要。

Max:最大响应时间,出现几率只不过是千分之一甚至万分之一,不重要。

Error%:本次测试中出现错误的请求的数量

Throughput:吞吐量——默认情况下表示每秒完成的请求数(Request per Second),当使用了 Transaction Controller 时,也可以表示类似 LoadRunner 的 Transaction per Second 数

KB/Sec:每秒从服务器端接收 到的数据量(只是接收),相当于LoadRunner中的Throughput/Sec
---------------------------------------------------------------------------------------
loadrunner测试参数说明:

响应时间: 取90%值,如果把响应时间从小到大顺序排序,那么90%的请求的响应时间在这个范围之内。重要。

每秒点击数 :hits per Second,每秒钟向服务器提交请求的数量。

TPS: Transaction per Second ,每秒事务数,一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程

Throughput(吞吐量): Loadrunner记录的Throughput是接收到服务器返回的所有字节数之和,与本地发出的字节数无关。

Throughput/Sec: 每秒的吞吐量。

对于BS架构的一般分析 响应时间、点击率、吞吐量、TPS(每秒事务数)。
对于CS架构的一般分析 TPS(每秒事务数)

---------------------------------------------------------------------------------------
Apache ab测试参数说明:

RPS: Request per Second,每秒处理的请求数
详见:
http://blog.chinaunix.net/u3/108043/showart_2260477.html

已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [建设 pv 网站] 推荐:

[转]你想建设一个能承受500万PV/每天的网站吗?如果计算呢?

- - 上善若水 厚德载物
你想建设一个能承受500万PV/每天的网站吗. 服务器每秒要处理多少个请求才能应对. PV是page view的简写. PV是指页面的访问次数,每打开或刷新一次页面,就算做一个pv. 每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量. 其中关键的参数是80%、40%.

你想建设一个能承受500万PV/每天的网站吗?如果计算呢?

- - 非技术 - ITeye博客
博客:http://elf8848.iteye.com. 你想建设一个能承受500万PV/每天的网站吗. 服务器每秒要处理多少个请求才能应对. PV是page view的简写. PV是指页面的访问次数,每打开或刷新一次页面,就算做一个pv. 每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量.

使用rrdtool统计网站PV和IP

- - Linux - 操作系统 - ITeye博客
现在网站服务器已经使用snmp进行监控,已经对CPU,内存,流量等进行了监控,但觉得还需要加一项监控,就是网站的PV和IP的监控,这样可以快速知道服务器负载上升是否是网站访问量增加的原因. 这几天初学 rrdtool,这个工具既能存储数据,又能画图,非常的方便. 下面是统计近一天的pv和ip图.

抛弃 PV,网站广告也按时间收费?

- - 疯狂简报·MADBRIEF
“同样一个品牌,曝光 1 秒和 5 秒有差别么. 这是《金融时报》(Financial Times)数字广告总监 Jon Slade 近日提出的一个看似简单问题,他无非是想证明注意力时间对于广告的重要性. 但在在线媒体行业,衡量广告投放效果的却是另外一套指标——PV 和 UV. 在广告主眼中,页面浏览量越大,意味着广告到达受众人数越广,投放效果也就越好.

从100PV到1亿级PV网站架构演变

- - 快课网
一个网站就像一个人,存在一个从小到大的过程. 养一个网站和养一个人一样,不同时期需要不同的方法,不同的方法下有共同的原则. 本文结合我自已14年网站人的经历记录一些架构演变中的体会. 1999年,我作了一个个人主页,在学校内的虚拟空间,参加了一次主页大赛,几个DREAMWEAVER的页面,几个TABLE作布局,一个DB连接,几行PHP的代码嵌入在HTML中,再用FTP传到服务器上就可以给别人展示一个网站.

一例千万级pv高性能高并发网站架构[原创]

- - 运维进行时
      受CU管理员的邀请参考“ 千万级pv高性能高并发网站架构与设计交流探讨帖”主题的交流,发表了一案例与大家分享.       一个支撑千万级PV的网站是非常考验一个架构是否成熟、健壮(本文不涉及软件架构的层面,有兴趣也可以讨论). 现抛出一个系统层面的架构,不保证是最优的方案,但也许适合你.

千万级pv高性能高并发网站架构与设计(转)

- - BlogJava-
高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”. 如果把来访用户比作来犯的"敌人",我们一定要把他们挡在800里地以外,即不能让他们的请求一下打到我们的指挥部(指挥部就是数据库及分布式存储). 如:能缓存在用户电脑本地的,就不要让他去访问CDN. 能缓存CDN服务器上的,就不要让CDN去访问源(静态服务器)了.

根据PV计算带宽及根据PV算并发

- - 企业架构 - ITeye博客
我们通常说的网站流量(traffic)就是指网站的访问量,是用来描述访问一个网站的用户数量以及用户所浏览的网页数量等指标,常用的统计指标包括网站的独立用户数量、总用户数量(含重复访问者)、网页浏览数量、每个用户的页面浏览数量、用户在网站的平均停留时间等. 网站访问量的衡量标准一个是IP,另一个是PV,常以日为标准,即日独立IP和PV来计算..

温故而知新「Fate/Zero」 PV+CM大回顾

- Adam - 和邪社
凌晨备受关注的10月新番《Fate/Zero》就要在nico上做8字幕全球放送了,在正是面相大家前. 大家再来回顾一下此前Fate/Zero为了宣传造势而制作的两段PV和连续7弹的CM吧.

Digg起死回生?Facebook添加其应用 PV一月增35%

- - TechWeb 今日焦点 RSS阅读
  Digg的网页浏览量在一月份增加35%,创下该公司自2010年10月份以来最大的流量记录.   网易科技讯 2月25日消息,据国外媒体报道,由于Facebook新添加Digg应用程序,Digg网站表现出新的发展活力.   报道称,软件工程师威尔·拉森尔(Will Larson)在一篇博文中表示,Digg的网页浏览量在一月份增加35%,创下该公司自2010年10月份以来最大的流量记录.