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

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

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

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

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

    于是,技术一脸懵逼。

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

  

  一,几个重要参数

      QPS每秒钟处理的请求数

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

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

     很多人经常会把并发数和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台保险

  三,最后

     以上,只是个人一些经验分享,有啥不对的地方,大伙轻点拍砖,有更好的建议欢迎回复,,

时间: 09-04

电商总结(六)系统容量预估的相关文章

系统容量预估

系统容量预估 前几天聊过,pv 和并发 的概念,也大概解释了 并发,带宽等指标的计算.感兴趣的朋友,可以看看我前面那篇文章:<聊一聊PV和并发>.今天再来聊一聊容量预估. 电商公司的朋友,,这样的场景是否似曾相识:  运营和产品神秘兮兮的跑过来问: 我们晚上要做搞个促销,服务器能抗住么?如果扛不住,需要加多少台机器? 于是,技术一脸懵逼. 其实,这些都是系统容量预估的问题,容量预估是架构师必备的技能之一.所谓,容量预估其实说白了就是,系统在down掉之前,所能承受的最大流量.这个事技术人员对于

电商抢购秒杀系统的设计_1_应用场景分析

电商抢购秒杀系统的设计_1_应用场景分析 概述 所谓知已知彼,百战不殆,在开始详细介绍实战中的抢购秒杀系统时,我们了解一些抢购秒杀系统系统面临的尴尬与难点.另外需要说明一点,下面的内容都是在工作中慢慢总结得来,我们团队也是慢慢摸着石头过河,甚至最初的的架构设计并非是抢购秒杀系统. 评估系统处理能力 理论基础:LNMP的并发考虑与资源分配 虽然有基础去评估我们应用系统的处理能力,但是电商购买的业务流程挺复杂,从登录,商品详情,购物车,填写收货地址,选择支付方式,创建订单,完成支付,以及隐含的定时服

电商商品秒杀系统架构分析与实战

网址:http://my.oschina.net/xianggao/blog/524943 0 系列目录 1 秒杀业务分析 2 秒杀技术挑战 3 秒杀架构原则 4 秒杀架构设计 4.1 前端层设计 4.2 站点层设计 4.3 服务层设计 4.4 数据库设计 4.4.1 基本概念 4.4.2 设计思路 5 大并发带来的挑战 5.1 请求接口的合理设计 5.2 高并发的挑战:一定要“快” 5.3 重启与过载保护 6 作弊的手段:进攻与防守 6.1 同一个账号,一次性发出多个请求 6.2 多个账号,一

中小型企业级电商涉及相关系统总结

随着全球信息化进程的不断发展和深入,电子商务日渐盛行,B2C模式开始崛起,越来越多的企业正在或计划建立自己的在线商务渠道,B2C电子网站必将雨后春笋般涌现.相对于大的电子商务平台,垂直细分类的B2C电子商务网站也有自己的优势.在专业化的背景下,垂直细分的电子商务网站能够给消费者提供更细致.更专业化的服务,同时,独立的网站也更有利于打造属于自己的电子商务品牌. 对于一个企业电子商务网站而言,电子商务平台不仅仅就是一个可以发布信息和购买东西的网站,原有网站的简单的宣传和信息发布功能已经不适应现代社会

微信连接电商入口 支付系统还不完善

目前微信正在连接电子商务的上下线运作.首先微信先连接人与人之间,随着人缘的增加,目前连接人与商业,实现电子商务的移动端应用:之后还要连接连接物与物. 微信连接人与人之间 微信连接第一重门,通过摇一摇保护用户严密隐私和完善的用户体验连接人与人.微信真正走向用户视野的并不是它的发文字.传图片.语音对讲的功能,而是充满趣味的摇一摇.张小龙在点评摇一摇时这样说:“微信的摇一摇是个以“自然”为目标的设计.整个界面没有菜单和按钮,几乎没有比它更简单的交互体验了,从自然而来到自然中去.”微信的摇一摇颠覆了所有

电商总结(八)如何打造一个小而精的电商网站架构

前面写过一些电商网站相关的文章,这几天有时间,就把之前写得网站架构相关的文章,总结整理一下.把以前的一些内容就连贯起来,这样也能系统的知道,一个最小的电商平台是怎么一步步搭建起来的.对以前的文章感兴趣的朋友可以看这个,http://www.cnblogs.com/zhangweizhong/category/879056.html 本文大纲: 1. 小型电商网站的架构 2. 日志与监控系统的解决方案 3. 构建数据库的主从架构 4. 基于共享存储的图片服务器架构 5. 移动M站建设 6. 系统容

大型网站架构系列:电商网站架构案例分析

上节课我们小组对淘宝网进行了简要的架构分析,这周我在课余时间对这类大型电商网站的某些具体架构技术进行了梳理和概括,并对一些架构方法进行更深层次的介绍,并且结合软件工程进行典型电商的需求分析. 一.典型电商案例 电商网站:比如阿里巴巴,京东商城,国美在线,汽车之家等.大型门户一般是新闻类信息,可以使用CDN,静态化等方式优化,一些交互性比较多的网站,可能会引入更多的NOSQL,分布式缓存,使用高性能的通信框架等.电商网站具备以上两类的特点,比如产品详情可以采用CDN,静态化,交互性高的需要采用NO

(转)大型网站架构系列:电商网站架构案例(1)

大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标). 根据实际需要,进行改造,扩展,支持千万PV,是没问题的. 本次分享大纲 电商案例的原因 电商网站需求 网站初级架构 系统容量估算 网站架构分析 网站架构优化 架构总结 电商网站案例,一共有三篇本篇主要说明网站的需求,网站初始架构,系统容量估算方法. 一.电商

大型网站架构系列:电商网站架构案例(1)

大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标). 根据实际需要,进行改造,扩展,支持千万PV,是没问题的. 本次分享大纲 电商案例的原因 电商网站需求 网站初级架构 系统容量估算 网站架构分析 网站架构优化 架构总结 电商网站案例,一共有三篇本篇主要说明网站的需求,网站初始架构,系统容量估算方法. 一.电商

关于电商ERP的想法

原文地址: http://www.chinaodoo.net/thread-465-1-1.html 试用了下odoo的淘宝订单处理模块,从整个业务流程上已经打通,如果要求不是很高的话,现有的功能基本上能满足大多数网店主的需求.但相比市面上针对淘宝.京东等平台开发的电商ERP,还是有很多地方可以完善.待完善后,Odoo其实很有竞争力的,甚至我觉得Odoo没有随电商的发展在电商ERP占一席地,实在是可惜了.也许是做传统ERP的团队不屑于这块.但是我公司旁边有一家软件公司,专门做淘宝订单打印,简单的