博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
假如想要建设一个能承受500万PV/每天的网站,服务器每秒要处理多少个请求才能应对?...
阅读量:5909 次
发布时间:2019-06-19

本文共 2756 字,大约阅读时间需要 9 分钟。

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

1、PV是什么:

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

2、计算模型:

每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量 。

注:其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时,有80%的请求发生一天的9.6个小时当中(很适合互联网的应用,白天请求多,晚上请求少)。

3、简单计算的结果:

((80%*500万)/(24小时*60分*60秒*40%))/1 = 115.7个请求/秒
((80%*100万)/(24小时*60分*60秒*40%))/1 = 23.1个请求/秒

4、初步结论:

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

5、留足余量:

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

6、最终结论:

如果你的服务器一秒能处理231.4--347.1个请求/秒,就可以应对平均500万PV/每天。
如果你的服务器一秒能处理46.2--69.3个请求,就可以应对平均100万PV/每天。
说明:
这里说明每秒N个请求,就是QPS。因为我关心的是应用程序处理业务的能力。

7、实际经验:

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/每天的。(已留有余量应对突然的访问高峰)

8、注意机房的网络带宽:
有人说以上条件我都满足了,但实际性能还是达不到目标。这时请注意你对外的网络的带宽,在国内服务器便宜但带宽很贵,很可能你在机房是与大家共享一条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带宽也不能满足要求了。你自已计算吧。

1G=1024M 1M=1024KB 1KB=1024B1Mb的宽带(运营商叫法)换算为下载速度(传输速率),是0.125MB/s,换算成MB换算成KB是128KB/s。

 

附:性能测试基本概念

一、基本概念:
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

三、Apache ab测试参数说明:

RPS:Request per Second,每秒处理的请求数

转载地址:http://xdvpx.baihongyu.com/

你可能感兴趣的文章
Android 缓存详解目录
查看>>
iOS开发中的错误整理,IOS9中canOpenURL调用失败分析
查看>>
iOS开发小技巧 - runtime适配字体
查看>>
资深程序员不一定当得了软件架构师
查看>>
个人实战演练全过程——No.1 最大连续子数组求和
查看>>
zip函数
查看>>
mysql 查询数据库内各表的占用大小
查看>>
第二章3
查看>>
花海漫步 NOI模拟题
查看>>
Spring MVC全局异常处理与拦截器校检
查看>>
2.Spring的Bean生命周期和组装方式
查看>>
jQueryUI中Datepicker(日历)插件使用
查看>>
margin相关属性值
查看>>
【Python & NLP】关于语料库标注——词性标注、分词标注、类别标签等-例如brat...
查看>>
多并发笔记
查看>>
iOS应用性能调优的25个建议和技巧
查看>>
结构体之间的转换
查看>>
asp.net发布webservice出现‘Could not write to output file ‘解决办法
查看>>
2018-2019-2 20165330《网络对抗技术》Exp5 MSF基础应用
查看>>
Web APP开发技巧总结
查看>>