你想建设一个能承受 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, 硬盘的性能很重要, 由其是数据库服务器. 一般的服务器都配 1.5 万转的 SAS 硬盘, 高级一点的可以配 SSD 固态硬盘, 性能会更好. 最最最最重要的指标是 "随机读写性能" 而不是 "顺序读写性能".(本例还是配置最常见的 1.5 万转的 SAS 硬盘吧)
3, 一台服务器跑 Tomcat 运行 j2ee 程序, 一台服务器跑 MySQL 数据库, 程序写的中等水平 (这个真的不好量化), 是论坛类型的应用 (总有回帖, 不太容易做缓存, 也无法静态化).
4, 以上软硬件情况下, 是可以承受 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(每秒事务数)
来源: http://server.51cto.com/sOS-589678.htm