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

作者:赵磊

博客: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

http://elf8848.iteye.com/blog/967049

时间: 2024-10-03 21:56:33

你想建设一个能承受500万PV/每天的网站吗?如果计算呢?(转)的相关文章

你想建设一个能承受500万PV/每天的网站吗?服务器每秒要处理多少个请求才能应对?

你想建设一个能承受500万PV/每天的网站吗?服务器每秒要处理多少个请求才能应对? 你想建设一个能承受500万PV/每天的网站吗? 500万PV是什么概念?服务器每秒要处理多少个请求才能应对?如果计算呢? PV是什么: PV是page view的简写.PV是指页面的访问次数,每打开或刷新一次页面,就算做一个pv. 计算模型:  每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量 .其中关键的参数是80%.40%.表示一天中有80%的请求发

建设一个能承受500万PV/每天的网站

你想建设一个能承受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.

建设一个能承受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分*6

想知道月销售额500万以上的微分销公司内部架构是怎样的?

微神 关注微信公众号:智云微神(QQ97200) 微分销教父带你了解更多分销玩法及动态,助你实现成功第一步! 作者简介: 微神(助理微信:3024160003),微分销教父,智云科技CEO,华南六少: 裂变分销第一自媒体人: 擅长移动互联探索及研发.大数据分析:目前已操盘多个以上微分销过亿项目! 智云科技(TEL:400-0628-323)专注分销商城开发,已有数十家月销百万客户. 本文系微神原创,转载请注明出处"智云微神",违者必究. 团队是一个企业的核心和灵魂,微分销出现的时机正是

中国人工智能人才缺口500万!现在学还来得及吗?

今年3月,人工智能首次被写入政府报告.7月,×××印发了<新一代人工智能发展规划>,提出面向2030年我国新一代人工智能发展的指导思想.战略目标.重点任务和保障措施--举全国之力,在2030年一定要抢占人工智能全球制高点. 毫无疑问,今年将成人工智能"关键年".据工信部统计数据显示,去年我国人工智能市场规模达239亿元,预计2018年将有望超过380亿元.然而,在人工智能市场规模不断扩大.形势一片大好的背后,也有隐患暗藏. 人才缺口达500多万 据统计显示,中国人工智能从业

Swift给每个开发者赢取500万的机会

[导语] Swift的横空出世,很多有想法的人已经发现其中的蕴含的巨大商机,而很多新手却只是云里雾里,只知道大家最近讨论Swift很欢乐.内行看门道,外行看热闹,说的就是这个理.如果你能把swift用得好,下一个千万富翁就是你! 一.Swift给技术论坛机会 开发者都知道IOS技术论坛,国内算CocoaChina老大,而Android的话当初是eoe论坛,现在开发者比较分散,Apkbus.eoe.以及各个手机厂商上的开发者论坛比如华为.小米也有一些人,还有另外一部分开发者不怎么逛论坛,专门在CS

谋哥:秦刚跟我说了一句话值500万!

[谋哥每天一干货,第六十二篇] 昨天晚上和谋天团的新会员麦城堡主(微信号qf825445)聊天,他这个人其实非常有想法,就是我们中国人说的聪明.堡主是70后,私营业主20年,期间涉足建材.餐饮.运输等传统行业,经历了多次失败.他现在感觉移动互联网的大势来临,目前转型搞快餐的订购配送App. 经过和他深入地交流,总结出他失败的原因我觉得是:"脑子太活,想法太多,项目太多." 中国人都非常聪明,经常在一边创这个业的时候,突然想到另外一个点子更加有前(钱)途,于是又去干另外的事情.想法多,野

Swift给每个开发者赢取500万的机会!不看一生后悔。

[导语] Swift的横空出世,很多有想法的人已经发现其中的蕴含的巨大商机,而很多新手却只是云里雾里,只知道大家最近讨论Swift很欢乐.内行看门道,外行看热闹,说的就是这个理.如果你能把swift用得好,下一个千万富翁就是你!一.Swift给技术论坛机会 开发者都知道IOS技术论坛,国内算CocoaChina老大,而Android的话当初是eoe论坛,现在开发者比较分散,Apkbus.eoe.以及 各个手机厂商上的开发者论坛比如华为.小米也有一些人,还有另外一部分开发者不怎么逛论坛,专门在CS

我卖掉北京500万的房产,在老家生活的这两年……

相信很多人都曾有和我一样的想法——把北上广深的房产卖了,拿着数百万巨款,再去三四线城市甚至是农村买个房子,做一个世外之人,潇洒.悠然地度过余生. 然而,绝大数人对此只是想想,并不敢真正付诸于行动.但,我是个例外,因为我是个有魄力的人. 01 大学毕业后,我在北京的一家国企工作多年,并有幸拿到了北京的户口.2005年,看到有朋友开始买房,于是我也鬼使神差地在北京西南三环买了一套商品房.当时房价是4000多一平米,我买了一套116平米的3居,房价高达40多万.这在当时对我来说是一个遥不可及的天文数字