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

故事的开始

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

  我们怎么回答？

• 客户过来反馈：你们系统响应好慢，经常超时；

  我们怎么解决？

我们该怎么解决

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