聊聊基准测试的MVP方案
上篇博客介绍了基准测试的一些思路和方法策略，这篇博客，聊聊基准测试的MVP（最小可行性方案）。。。web
思惟导图缓存
1、测试策略服务器
| 策略名称 | 阈值 | 运行时间 | 性能指标 | 基线 | 注释 |
| 并发测试 | CPU75%+Error0.01% | 10-30min | 并发数、TPS、RT、内存占比 | 并发基线 | 并发测试获得的结果能够做为实际生产环境峰值流量下的性能表现 |
| 容量测试 | CPU＜100%+Error0.01% | 10-30min | 并发数、TPS、RT、内存占比 | 容量基线 | 通常来讲90%便可做为阈值 |
| 双节点测试 | CPU＜100%+Error0.01% | 10-30min | 并发数、TPS、RT、内存占比 | 负载均衡基线 | 应考虑随着服务节点的增长，性能的递减效应，通常每增长1个节点，理论上性能递减2-5%（以实际测试结果为准） |
| 稳定性测试 | CPU75%+Error0.01% | ≥12h | 并发数、TPS、RT、内存占比 | 稳定性基线 | 稳定性的运行时间根据具体状况调整，通常不能低于12h |
PS：今天和朋友聊起这个话题，朋友说还应该有一个高可用测试，不过仔细想了下，高可用我的认为应该更侧重容灾和失效恢复测试领域。。。网络
2、系统配置并发
nCnG：性能测试可能涉及多个系统，每一个系统的服务器配置存在不一样，所以要明确不一样系统的硬件配置，这样也方便针对性的设定测试策略以及分析性能指标。负载均衡
内存分配：这里主要指的是堆内存分配，须要根据具体的服务器配置进行分配，固然，最好针对性的进行配置测试来肯定内存的合理分配。分布式
应用版本：以JDK为例，每一个版本都有不一样的改进和优化，且被测系统环境应与实际生产环境保持一致的版本。工具
线程池：线程池数量，也是一个须要重视的问题（我本人就遇到过因为线程耗尽最终致使的OOM）。性能
最大链接数：容器、DB的最大链接数，消息队列的消费者数量，也是一个须要考虑的因素。测试
缓存策略：为了提升系统应对大流量冲击以及提升可用性，缓存是离不开的一种方法，这里须要关注的是缓存命中以及缓存穿透的问题。
3、环境选型
SIT：通常来讲不多在SIT环境进行基准测试，缘由不少，好比：交叉影响、稳定性、配置不一致甚至多个项目部署在同一个SIT环境等。
UAT：大多数时候，性能测试都是在UAT环境下进行，由于UAT相比SIT稳定性更好，已经经过了系统测试阶段，且进行性能测试的成本相比生产环境更低。
PAT：在生产环境进行性能测试，测试结果的准确性是最高的，但也须要考虑到这几点因素：数据污染、隔离、改形成本、不能影响实际生产业务运行、测试时间等。
4、执行方式
稳定施压：上面提到的并发、容量、双节点、稳定性测试通常都是基于一个固定的并发数来模拟负载进行测试，具体的并发数值须要根据实际的用户数、使用频次、业务场景考虑。
浪涌测试：在实际生产环境中，有时候存在这种状况：短期内有很高的流量冲击，好比限时秒杀等场景。
阶梯式加压：阶梯式加压是寻找系统拐点的最有效的方式。
5、风险预估
在进行基准测试前，要考虑到以当前的环境、业务模型、系统配置可能存在哪些影响测试的因素，以及影响程度、应对策略，好比：网络延时、网络波动、交叉影响等。
6、业务模型
基准测试的业务模型选择，不管是从实施难易程度或者成本考虑，通常都以如下三种类型出发：
核心业务：通常来讲核心业务的重要性和使用频次都是优先级最高的，好比支付、订单。
高频次业务：查询、更新等高频操做场景，也是须要重点关注的场景。
平常轮询业务：基准测试的实施前提就是可重复执行和长时间进行测试，这样才能够进行对比和统计，来分析长期的系统性能基线变化。
7、工具选型
性能测试过程当中，须要借助的工具不少，使用占比最高的为如下几种：
负载生成工具：好比Jmeter、Loadrunner、Locust、Gatling、Artillery。
应用监控工具：主要用来监控服务端的各项指标，好比Nmon、Skywalking。
代码分析工具：好比SonarQube、Codacy，通常结合持续集成工具来进行。
日志分析工具：好比如今最经常使用的ELK。
DB监控工具：好比Zabbix、DBMonitor。
8、异常处理
在性能测试过程当中，常常会遇到一些异常状况，好比超时、失败、接口依赖、敏感数据等状况，针对这些状况，设计合理可行的解决方案。
9、统计维度
测试的结果必定要方便从各个层次、维度进行统计，这样能够为后续的分析提供更可靠的数据来源，以响应时间来讲，通常从如下几个维度统计：
| 维度 | 举例 | 适用测试策略 |
| 峰值 | 取系统CPU在75%左右的表现进行屡次统计，加权平均计算 | 并发测试 |
| 极值 | 取系统CPU＜100%的表现进行屡次统计，加权平均计算 | 容量测试 |
| 平均值 | 平均值的统计，比较适用于响应时间波动不大的状况 | 双节点测试 |
| 百分比值 | 对于服务集群部署或者分布式部署的系统，百分比值，更能反映系统的性能表现 | 稳定性测试 |
10、查询展现
上篇博客介绍过，基准测试的结果必定要便于统计展现，能够明了直观的展现给相关人员，通常来讲，能够从不一样维度，粒度从大到小的形式进行查询展现，好比：
| 维度 | 说明 |
| 时间范围 | 好比默认展现最近一个月的基准变化，也能够设置根据时间来查询不一样时间范围内的基准表现 |
| 系统名称 | 对于涉及对个业务系统的状况，能够根据系统名称进行查询 |
| 业务模型 | 从核心业务、高频次业务、平常轮询业务等维度，进行展现 |
| 测试策略 | 根据基准测试的策略，从并发、容量、双节点、稳定性等角度进行查询展现 |
能够经过web页面、仪表盘、折线图、树状图等形式，进行不一样角度的系统基准表现展现，具体如何设计，能够进行需求调研，而后针对性的设计。