你知道你的系统接客能力吗

故事的开始
  • 老板过来问: 我们系统能承受多大的用户量? 应该部署多少服务才能承载公司当前和未来一段时间的业务?

    我们怎么回答?

  • 客户过来反馈:你们系统响应好慢,经常超时;

    我们怎么解决?

我们该怎么解决

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参数。