标签：破坏 策略 服务器 竞争条件 好的 内容 多少 targe 固定
《如何做好性能压测》系列专题分享的第四期，该专题将从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解，以帮助大家构建完整的性能压测的理论体系，并提供有例可依的实战。
该系列专题分享由阿里巴巴 PTS 团队出品，欢迎在文末处加入性能压测交流群，参与该系列的线上分享。
第一期：《压测环境的设计和搭建》，点击这里。
第二期：《性能压测工具选型对比》，点击这里。
第三期：《阿里巴巴在开源压测工具 JMeter 上的实践和优化》，点击这里。
第四期：《并发模式与 RPS 模式之争，性能压测领域的星球大战》
负载测试：
一种验证性测试，它的目的是验证预设负载条件下的性能表现是否达到性能目标（可用性、并发数/RPS、响应时间等），在达到性能目标之后不会继续增加负载。
稳定性测试：
负载测试的一个子集，侧重于发现、验证只有经过长时间的运行才会暴露的问题。比如内存泄漏、FGC 等。
压力测试：
一种破坏性测试，尝试探测应用或者基础设施的极限能力。因此压力测试过程中会一直增加负载直到部分性能指标不再符合性能预期。压力测试能发现仅在高负载条件下出现的同步问题、竞争条件、内存泄漏等。通过压力测试我们还可以确定应用服务在什么条件下会变得不可用，不可用的现象，以及可以通过哪些监控指标来监控即将发生的不可用，压测结果通常可以为限流等管控系统提供数据支撑。
容量测试：
往往与容量规划一起进行，是在保证用户体验不受影响（稳定性）的前提下，使有限的资源的利用率最大化（成本）。也可以用它来预估未来用户量增长到某个量级的情况下，需要多少资源（例如处理器、内存、磁盘、网络带宽）来支持。
业务场景建模
一般情况下，在性能测试中模拟每个用户可能的操作场景基本上是不可能实现的，我们必须要关注的性能场景包括但不限于：
在测试具有大量新功能的业务时，往往需要与业务方一起确认预期内有哪些功能点可能会被高频使用，需要与研发人员确认哪些功能虽然使用频率不高，但是存在性能隐患、容易引起雪崩效应；在测试已经上线的功能时，还可以通过业务监控、系统日志来分析现有用户的行为模式，得到更加逼近真实用户行为的业务场景。
业务场景的操作路径可以借助一些可视化的工具来描述，这部分工作相对比较简单，不再详细深入。我们详细说明一下比较常见的延时策略。
思考时间：思考时间模拟的是用户在等待响应、阅读页面内容、表单填写等延迟操作的场景。每个人的阅读速度、输入速度都存在非常大的差异，决定了每个人的思考时间也是不一样的，在性能测试配置中有常见的四种延时模型覆盖了绝大部分的延时场景：
我们通常可以通过以下方式对思考时间进行建模：
确认监控指标
在性能测试执行过程中，往往需要实时观察各项指标是否正常，包括客户端指标、应用服务器、数据库、中间件、网络入口等各方面的指标。更重要的是，监控的过程是发现系统瓶颈的过程，监控数据是性能基线管理、容量规划甚至是高可用架构的重要基础。我们通常需要关注的监控指标包括：
最理想的状态是，这些监控指标能够与性能测试工具集成，在一个操作界面上展示各个维度的监控数据，并能够基于策略来智能化、自动化识别指标异常。这对快速、准确的定位压测过程中可能出现的各种问题是至关重要的。
原文链接：https://mp.weixin.qq.com/s/k6MRiK0UE9tawxwZm3SMMw
标签：破坏 策略 服务器 竞争条件 好的 内容 多少 targe 固定
原文地址：https://www.cnblogs.com/syw20170419/p/12778933.html
