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

本文介绍如何构建能够承受500万PV/天的网站,涉及服务器配置、压力测试标准、网络带宽需求等内容。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

博客: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测试参数说明:

 

<think>好的,用户问的是Karmada的Deployment是否支持PV/PVC。首先,我需要回忆一下Karmada的基本架构和功能。Karmada是一个多云多集群管理项目,它主要处理的是跨集群的资源分发和策略管理,对吧?用户可能是在部署有状态应用时遇到了存储问题,知道是否可以通过Karmada来管理PV/PVC。接下来,我需要确定PV/PVC在Karmada中的支持情况。PVPVC是Kubernetes中存储管理的核心概念,而Karmada本身并不直接管理存储资源,因为它主要关注于跨集群的工作负载分发。不过,用户可能希望在使用Karmada部署Deployment时,能够自动处理存储的分配,比如在多个集群中自动创建PV/PVC,或者同步存储配置。然后,我需要考虑Karmada如何处理存储资源。根据之前的了解,Karmada的PropagationPolicy可以分发资源到成员集群,但存储资源通常是集群本地的,每个集群的存储配置可能不同。因此,直接分发PVC可能不可行,因为不同集群的StorageClass、存储后端等可能不同。用户可能需要为每个集群单独配置PVC,或者使用动态供应。 接下来,我需要思考如何正确地在Karmada中配置带有PVC的Deployment。可能的解决方案是使用OverridePolicy来覆盖PVC的配置,使其适应不同的集群。例如,为每个集群指定不同的StorageClass。同时,需要确保每个成员集群都有对应的StorageClass和存储后端,这样PVC才能正确绑定PV。 然后,我需要验证这个思路是否正确。查看Karmada的文档或社区讨论,确认是否有类似的使用案例。例如,用户是否需要在多个集群中部署有状态应用,每个集群使用本地存储,这时候可能需要为每个集群单独配置PVC,并通过Karmada的策略进行分发和覆盖。另外,用户可能需要使用动态PV,这样PVC可以根据集群的StorageClass自动创建PV。这时候,PropagationPolicy需要分发StorageClass、PVC以及Deployment。但StorageClass通常是集群特定的,可能不适合跨集群分发,所以需要每个集群预先配置好对应的StorageClass,然后通过OverridePolicy来修改PVC的StorageClass名称。 最后,总结解决方案:Karmada的Deployment支持PVC,但需要合理配置PropagationPolicy和OverridePolicy,确保每个集群的存储配置正确。同时,存储资源需要每个集群独立管理,Karmada负责分发和适配PVC的配置。</think>Karmada的Deployment资源本身支持PVC/PV配置,但需要特别注意跨集群的存储适配问题。以下是详细解决方案: **核心原理**: 1. Karmada通过PropagationPolicy分发资源到成员集群 2. PVC/PV属于集群本地资源,需要特殊处理 3. 存储配置需要与目标集群的StorageClass匹配 **完整部署方案**: ```yaml # deployment-with-pvc.yaml apiVersion: apps/v1 kind: Deployment metadata: name: mysql spec: replicas: 1 selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql:5.7 volumeMounts: - name: mysql-persistent-storage mountPath: /var/lib/mysql volumes: - name: mysql-persistent-storage persistentVolumeClaim: claimName: mysql-pvc --- # pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi storageClassName: standard # 需要与成员集群匹配 ``` **策略配置文件**: ```yaml # propagation.yaml apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: mysql-propagation spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: mysql - apiVersion: v1 kind: PersistentVolumeClaim name: mysql-pvc placement: clusterAffinity: clusterNames: - member-cluster-1 - member-cluster-2 ``` **存储适配方案**: ```yaml # override-storageclass.yaml apiVersion: policy.karmada.io/v1alpha1 kind: OverridePolicy metadata: name: storage-override spec: resourceSelectors: - apiVersion: v1 kind: PersistentVolumeClaim name: mysql-pvc overrideRules: - targetCluster: clusterNames: - member-cluster-1 overriders: plaintext: - path: "/spec/storageClassName" operator: replace value: "cluster1-storage" - targetCluster: clusterNames: - member-cluster-2 overriders: plaintext: - path: "/spec/storageClassName" operator: replace value: "cluster2-storage" ``` **验证步骤**: ```bash # 检查PVC分发状态 kubectl get pvc --all-namespaces --kubeconfig=karmada-apiserver.config # 查看实际集群中的存储绑定 kubectl --context=member-cluster-1 get pvc kubectl --context=member-cluster-2 get pvc ``` **多集群存储管理方案对比**: | 方案 | 优点 | 缺点 | 适用场景 | |------|------|------|----------| | 静态PV分发 | 配置明确 | 需要预创建PV | 小规模固定存储 | | 动态PVC | 自动创建PV | 依赖StorageClass | 多云环境 | | CSI跨集群 | 统一存储接口 | 需要CSI驱动支持 | 专业存储设备 | | 本地卷 | 性能好 | 无法迁移 | 单集群部署 | **注意事项**: 1. 每个成员集群需要预先配置对应的StorageClass 2. PV的实际可用性取决于集群的存储基础设施 3. 有状态应用的副本数需要与存储方案匹配 4. 跨集群数据同步需要额外方案(如Velero)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值