企业级电商平台提供商,为企业级商家提供电商平台搭建及解决方案服务

全国热线:4008-868-127

电商总结(六)系统容量预估

2018-10-18 1093
分类: 技术干货

前几天聊过,pv 和并发 的概念,也大概解释了 并发,带宽等指标的计算。感兴趣的朋友,可以看看我前面那篇文章:《聊一聊PV和并发》。今天再来聊一聊容量预估。

前几天聊过,pv 和并发 的概念,也大概解释了 并发,带宽等指标的计算。感兴趣的朋友,可以看看我前面那篇文章:《聊一聊PV和并发》。今天再来聊一聊网上商城系统网站容量预估。

电商公司的朋友,,这样的场景是否似曾相识:

运营和产品神秘兮兮的跑过来问:

我们晚上要做搞个促销,服务器能抗住么?如果扛不住,需要加多少台机器?

于是,技术一脸懵逼。

其实,这些都是独立商城网站系统容量预估的问题,容量预估是架构师必备的技能之一。所谓,容量预估其实说白了就是,系统在down掉之前,所能承受的最大流量。这个事技术人员对于系统性能了解的重要指标。常见的容量评估包括流量、并发量、带宽、CPU,内存 ,磁盘等一系列内容。今天就来聊一聊容量预估的问题。

一,几个重要参数

 QPS:

每秒钟处理的请求数。

并发量: 系统同时处理的请求数l;

响应时间:  一般取平均响应时间;

很多人经常会把并发数和QPS 混淆,理解了上面三个要素的意义之后,就能推算出它们之间的关系:QPS = 并发量 / 平均响应时间

二,容量评估的步骤与方法

1:预估总访问量

如何知道总访问量?对于一个运营活动的访问量评估,或者一个系统上线后PV的评估,有什么好的方法?

最简单的办法就是:询问业务方,询问运营同学,询问产品同学,看产品和运营对此次活动的流量预估。

不过,业务方对于流量的预估,应该就两个指标,pv 和 用户访问数。技术人员 需要更具这两个数据,计算其他相关指标,比如  QPS 等。具体如何计算可参照我前面一篇 pv和并发 的文章。 

2:预估平均QPS

总请求数 = 总PV * 页面衍生连接数

平均QPS = 总请求数 / 总时间

比如:活动落地页1小时内的总访问量是30w pv,该落地页的衍生连接数为30  ,那么落地页的平均QPS

(30w * 30) /(60 * 60) = 2500, 

3:预估峰值QPS

系统容量规划时,不能只考虑平均QPS,而是要抗住高峰的QPS,如何评估峰值QPS呢?

这个要根据实际的业务评估,通过以往的一些营销活动的 pv 等数据进行预估。一般情况,峰值QPS大概是均值QPS的3-5倍,日均QPS为1000,于是评估出峰值QPS为5000。

不过,有一些业务例如“秒杀业务”比较难评估业务访问量,这类业务的容量评估不在此讨论。

4:预估系统、单机极限QPS

如何预估一个业务,一个服务器单机的极限QPS呢?

这个性能指标,是服务器,最基本的指标之一,所以没有其他的办法,就是压力测试。通过压力测试,算出服务器的单机极限QPS 。

在一个业务上线前,一般都需要进行压力测试(很多创业型公司,业务迭代很快的系统可能没有这一步,那就悲剧了),以APP 推送 某营销活动为例(预计 日均QPS 1000,峰值QPS 5000),业务场景可能是这样的:

1)通过 APP 推送一个活动消息 

2)运营活动H5落地页是一个web站点

3)H5落地页由缓存cache、数据库db中的数据拼装而成

通过压力测试发现,web 服务器 单机只能抗住1200的QPS,cache和数据库db 能抗住并发压力,(一般来说,1%的流量到数据库,数据库120 QPS还是能轻松抗住的,cache的话QPS能抗住,需要评估cache的带宽,这里假设cache不是瓶颈),这样,我们就得到了web单机极限的QPS是1200。一般来说,生产系统不会跑满到极限的,这样容易影响服务器的寿命和性能,单机线上允许跑到QPS 1200 * 0.8 = 960 。

扩展说一句,通过压力测试,已经知道web层是瓶颈,则可针对web 相关的做一些调整优化,以提高web 服务器 的单机QPS 。还有,压力测试工作中,一般是以具体业务的角度进行压力测试,关心的是某个具体业务的并发量和QPS。

5:回答最开始那两个问题

需要的机器  = 峰值QPS / 单机极限 QPS 

好了,上述已经得到了峰值QPS是5000,单机极限QPS是1000,线上部署了3台服务器:

(1)服务器能抗住么? -> 峰值5000,单机1000,线上3台,扛不住

(2)如果扛不住,需要加多少台机器? -> 需要额外2台,提前预留1台更好,给3台保险

三,最后

需要注意的是,以上都是计算单个服务器或是单个集群的容量,实际生产环境是由web, 消息队列,缓存,数据库 等等一系列组成的复杂集群。在分布式系统中,任何节点出现瓶颈,都有可能导致雪崩效应,最后整个集群垮掉 (“雪崩效应”指的是系统中一个小问题会逐渐扩大,最后造成整个集群宕机)。所以,要了解规划整个平台的容量,就必须计算出每一个节点的容量。找出任何可能出现的瓶颈所在。

文章来源:博客园

<数商云(www.shushangyun.com)是国内知名企业级电商平台提供商,为企业级商家提供最佳的系统开发(多种模式电商平台搭建:B2B/B2B2C/B2C/O2O/新零售等)、供应链系统搭建及电商行业解决方案服务>

网站声明:以上内容为数商云电子商务系统网站的原创文章,如需转载,请注明出处,谢谢合作!
评论
剩余-200
发表
电商头条文章
1 深度解析什么是WMS仓库管理系统?
WMS一般具有以下几个功能模块:管理单独订单处理及库存控制、基本信息管理、货物流管理、信息报表、收货管理、拣选管理、盘点管理、移库管理、打印管理和后台服务系统。
2 阿里中台变“厚”,企业中台路在何方?
2015年,阿里提出“小前台、大中台”战略,一经推出,震惊业界。在此之前阿里已经足足准备了6年,“中台战略”的推出是水到渠成的事情。看到这里,各企业的CIO们自己掂量掂量,你家的中台准备了几年?
3 企业级API网关接口开发,提高微服务体系架构稳定性、响应效率
API网关是提供服务开放和共享的企业级PaaS平台,提供发布管理、统一认证鉴权、流控、协议转换、服务审计等功能,帮助用户实现内部多系统间,或者内部系统与外部系统之间实现跨系统、跨协议的服务能力互通。
4 打造企业级微服务平台架构,分布式应用场景管理
微服务平台架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务。
5 企业需要的中台是什么?答案是:指挥官体系
直接讲观点,我认为“中台” 概念没有反应这件事情的本质,我希望把它命名为“指挥官体系”。企业需要的是指挥官体系,大家热议的中台的本质对于企业而言真正需要的其实是指挥官体系。从今天开始,忘记“中台”, 记住“指挥官体系”这五个字。
热门文章

填写以下信息, 免费获取方案报价

姓名
手机号码
你的职位
企业名称
开发类型
请选择开发类型
  • B2B电商平台
  • B2C电商平台
  • B2B2C电商平台
  • O2O电商平台
  • 供应链管平台
  • 采购管理平台
  • 供应商管理平台
  • B2B渠道订货平台
  • 其他
  • 需求描述

    请您填写以下信息,马上预约演示

    姓名
    手机号码
    你的职位
    企业名称

    恭喜您的需求提交成功

    尊敬的用户,您好!

    您的需求我们已经收到,我们会为您安排专属电商商务顾问在24小时内(工作日时间)内与您取得联系,请您在此期间保持电话畅通,并且注意接听来自广州区域的来电。
    感谢您的支持!

    console.log();