你知道你的系统接客能力吗
故事的开始
老板过来问: 我们系统能承受多大的用户量? 应该部署多少服务才能承载公司当前和未来一段时间的业务?
我们怎么回答?
客户过来反馈:你们系统响应好慢,经常超时;
我们怎么解决?
我们该怎么解决
1、量化业务的增长,也就是预估并量化系统在未来一段时间内的增长情况;
包括:
- 自然增长量(统计系统过去一段时间的增长量来估计)
- 预期增长量 (业务活动例如各种促销活动等)
2、确定当前的系统容量,包括了解系统的组成以及每个组成部分的容量;
我们现在一般都是采用分布式的微服务架构,每个系统都会有若干功能独立的微服务组成,因此,我们要预估一个系统的当前承载量,首先得了解系统的结构,熟悉各微服务之间的调用关系,并且知道线上有多少个微服务实例以及每个微服务的容量情况,从而确定整个系统的容量(取决于瓶颈点,系统短板);
3、通过压测确定系统的最大容量
- 确定整个系统瓶颈
- 确定单节点服务的容量
估算当前水位=当前总qps/(单台机器极限qps机器数)100%
然后根据系统容量来确定什么时候该加机器来扩容了
压测工具
Jmeter
Jmeter是Java开发的一款压测工具。Jmeter是工作在协议层,比如发起http请求。建立多线程,模拟用户的并发请求,以达到对服务器产生压力目的。因为有断言可以插入检查点,因此也能做为功能测试,接口测试的工具。Jmeter支持的协议比较多,并且能加载自己开发的jar包来扩展功能,比如压测dubbo接口。
Jmeter-性能测试场景设计
- 单场景
- 混合场景
并发压力爬升模型
PV计算模型
每台服务器每秒处理请求的数量=((80%总PV量)/(24小时60分60秒40%)) / 服务器数量
一天中有80%的请求发生在一天的40%的时间内
根据PV模型确定压测并发数
性能测试的几个指标
1、TPS:每秒钟处理完的事务次数,一般TPS是对整个系统来讲的
2、RT:响应时间; Avg RT,90% RT,Min, Max
3、QPS: 每秒钟处理完请求的次数
4、Std.Dev: 标准差; 标准差越小,说明波动越小,系统越稳定
全链路压测
评估出单点单个服务的性能,这样就足够了么?
单机压测没有考虑到依赖环节压力都比较大的情况
对整个全交易链条上的各个环节的系统承压能力清楚么?
高仿真模拟的场景验证整个站点的容量、性能和瓶颈点
全链路压测
全链路监控
代表:Pinpoint分布式系统的跟踪系统;追踪每个请求的完整调用链路,收集调用链路上每个服务的性能数据。
调用栈(CallStack)
在分布式环境中为每个调用
生成代码级别的可视图,
在单个视图中定位瓶颈和失败点。
查看应用上的其他详细信息,
比如CPU使用率,
内存/垃圾回收,TPS,
和JVM参数。