昨天一大神又做了一次精彩的分享,关于服务容量预估和常用的优化策略。鄙人将分享内容case及个人理解写出来,一在自我回顾总结,二在分享给大家,一起讨论。
Case
用户运营提出某活动价促销需求(优惠力度很大),且活动商品无限量供应。计划给1000w用户发送促销短信。
问:你是负责该活动的RD,这次活动需要加机器吗?
回答这个问题需应基于历史活动的访问量、机器性能指标表现而定;且是否加机器首先还得清楚机器硬件配置数据、从web到db各节点层的最大、最优访问数值。
笔者考虑思路是,活动、促销必与并发量、接口qps相关;且前期研究系统服务限流时思考过这样两个问题
1、如何预估接口qps?
2、以及如何统计线上接口qps?
后一个问题当然简单,最终采用awk命令方可得到数据。但第一个问题最直接的QPS测量方式除了模拟线上环境进行接口压测之外,开发人员应有一个哪种合理的思路去进行预估,笔者一直没有想出一个比较好的方案。但肯定需要有这么一套完备的思路(体现互联网老兵久经沙场的牛逼之处)。
看看大神思路
服务容量的核心指标
1、吞吐量(Throughput):每秒钟可以处理的请求数、任务数
2、系统延迟(Latency):系统处理一个请求、任务的延迟(请求处理时间+数据传输时间)
服务容量预估
一、服务本身访问量、QPS预估
1、估算活动总访问量,通过PV、UV、交易量数据评估
1000w营销短信活动当天发送完
UV:1000w * 10% = 100w(估算10%的用户收到短信回打开链接)
PV:100w * 3 = 300w(估算其中每个用户可能会来回打开3次)
注:估算数据也需要根据历史实际活动数据统计得来,是个概率值。
UV:Unique Vistor,1天内同一访客的多次访问只计为1个访客,以cookie为依据
PV:page view 用户每打开一个页面便记录1次PV,多次打开同一页面则浏览量累计
IP:独立IP数,同一IP无论访问了几个页面,独立IP数均为1
2、估算活动平均QPS
短信发送时间一般为:8:00 – 20:00
13h * 60 * 60 = 46800 ~= 4w 秒
300w 链接请求/ 4w 秒 = 75 次访问每秒
3、活动峰值QPS
这个就需要根据系统历史访问情况,统计线上最高的qps量是多少,进行大致预估。除awk命令外,笔者提供一个比较笨的方法,如下:
cat trade.log|grep 'createTrade result:' | cut -d' ' -f2 | cut -d':' -f3 | uniq -c
取增量 | 一个请求取一行 | 把时间截取出来 | 把秒数截取出来 | 去重取计数
4、估算单机极限QPS *
基于网站流量分布:峰值流量 / 平均流量 = 70k / 50k = 1.4
峰值QPS = 75 * 1.4 = 105(活动的平均QPS *最高倍数 约等于最高qps)
5、确定节点数量
通过以上针对该活动期间的系统访问量、系统平均QPS以及最高QPS的预估,对活动的峰值本身有了一个大致的范围。接下来就需要对系统中的固有瓶颈,如WebServer 最高QPS、MySql读写请求最大值等,结合这些参数进行评估。
二、各网络节点性能指标
常用性能指标
1、操作时延:
Heap:1us
Off-Heap: 10us
Memory Mapped File: 100us
文件顺序读写:接近ms
Socket: >1ms
2、MySQL读写 :2 000RW/秒,ms级
3、Redis :40 000RW/秒,ms级
4、Tomcat:3 200req/秒,13ms延迟,40线程
5、代码执行开销:逻辑分支、对象创建、
6、框架、软件执行开销:Spring、MyBatis、Tomcat
7、外部依应用行开销:JDBC、Rpc、Http、Redis
8、内部应用执行开销:锁、条件
9、其他硬件开销:IO、带宽、CPU
三、Case:结合以上数据分析某接口最大QPS值
actionA通过了两次mysql查询,3次写入操作,最后将请求返回页面。us忽略不计,3次db IO姑且评估action A执行时间为3ms
Tomcat:1ms时延下,tomcat吞吐量为20k,20k/3 = 6.6k
MySQL:2000/3 = 666
最终actionA的吞吐量为:666 (短板理论,系统性能取决于最小吞吐节点)
最终确定节点数量:
通过计算,活动请求峰值QPS为105,单机能承担的极限QPS为666,666 > 105, 理论节点数量为1即可。实际部署了2个服务节点。不需要加机器。
四、总结
这就是容量预估的整理分析流程。想必618 双11之前无数工程师或通过工具、或凭借历年团队项目经验,不断重复的评估多少台机器能抗住。
另外除技术本身,我从这位同事身上看到了一点:经验这东西是装不出来的,也是我或缺的。需要在日常工作中多思考,多提问,多设想,多找解决方案。看别人很多参数、指标,不同延时下tomcat的最大吞吐量、不同业务逻辑每个接口大致执行时间这些确切的数据随便信手拈来,很是屌屌的。