实现并维持性能
 在系统的使用和发展过程中防止性能降低。 |
|---|
开发并不是一次性的工作。 它是一个持续的过程。 随着功能发生变化，性能应该也会变化。 用户模式和配置存在差异，甚至其他 Azure 架构良好支柱中的优化也会发生变化。 任何更改都可能会给工作负载资源带来压力。
保护系统免受更改，使其不会在性能目标上倒退。 在开发过程中集成测试和监视。 使用真实的负载测试系统在生产中的性能，并在生产之前通过自动测试模拟该负载。 在这两种情况下，都应有用于验证的监视做法。
在整个开发生命周期中，在不同阶段执行各种类型的测试。 在初始阶段，测试概念证明，以确保性能结果并非完全意外。 随着开发的进展，进行手动、低工作量的测试来建立基准。 在生成阶段，开始开发自动例程性能测试，以评估测试计划中定义的延迟、压力级别、负载容量和其他特征。
监视必须是这项工作不可或缺的一部分，而不是孤立的练习。 可以查看系统及其资源随时间推移的表现。 然后，可以微调它们以最大化其价值，并确保它们继续满足性能标准。
请记住，性能目标随时间而变化，以应对变化。 根据测试和监视的指标更新性能模型。 清楚地指示流的性能的增加、减少或不影响。
始终准备好与业务利益干系人重新谈判和重置预期。
示例场景
Contoso 活动解决方案提供了一款产品，活动入口人员可以使用它扫描移动设备上的门票，让获授权者快速进入凭票场所。 该系统既具有完全离线模式，也可为担心门票重复的场所作为云连接版本使用。 离线模式性能很高，但在线模式未达到其性能目标。 开发团队最近投资了几个开发周期来处理它，现在性能得到了很大的改进并正在满足目标。 业务利益干系人希望尽快扩大其客户群，以支持更大的场所。
测试开发中的性能
将性能测试正式化为可批准或拒绝发布提升以及最终部署到生产环境的质量关口。
这些检查点可确保在继续下一步之前，每个部署阶段都满足所需的性能标准。 检查点有助于防止意外的性能退化。 例如，如果性能明显低于预期，则在改进之前可以阻止发布。
Contoso 的挑战
- 该团队投入了大量时间和精力来在应用程序的在线版本中实现可接受的性能，但它们目前没有任何系统来防止退化。
- 他们计划添加的下一项功能是让活动场所能够选择在扫描之外显示与会者的照片，作为额外的验证。 额外的照片查找和下载可能会降低此过程的速度。
- 如果没有正式的过程，在线和离线版本的性能可能会受到附加功能的负面影响，并可能低于其目标。
应用方法和成果
- 该团队将自动性能测试集成到生成管道中。 通过在生成管道中实施严格的基于性能的“进行/不进行”条件，团队更有信心新功能不会在性能退化的情况下发布。
- 该团队实施此测试是明智的，因为它在最新版本的生成中捕获了一个 bug。 该 bug 强制应用尝试连接到 Internet 以在扫描程序设置为离线模式时下载图像，从而导致每次门票扫描都出现超时。 使用自动测试捕获此 bug 后，团队可以在发布新版本之前修复该 bug。
通过可观测性进行优化
设置一个可重复的过程，用于监视生产中的实际事务，以及在性能目标上的偏差。 此外，在生产中使用综合事务，并针对性能退化设置监视警报。
你希望深入了解系统在现实的负载下的实际性能，这是无法通过测试来模拟的。 然后，你可以主动识别问题和改进领域，例如潜在瓶颈、未充分利用的资源和其他问题。
Contoso 的挑战
- 在使用在线门票验证的活动中，后端系统被重度使用。
- 应用程序性能监视 (APM) 系统已到位，但它尚未用于监视生产事务的运行状况。
应用方法和成果
- 该团队已决定采用更新的过程来更好地捕获运行状况指标：
- 他们根据性能百分位和性能离群值配置了警报。 没有警报表示系统在大多数门票扫描中的性能在可接受范围内。
- 离线活动结束后，将批量上传门票扫描的遥测，这些指标也会经历一个流程以查找与可接受的性能之间的偏差。
- 该团队还实施了综合事务测试来增强其性能监视。 由于几乎所有活动都发生在周末和晚上，该团队在整个星期内都使用综合事务测试来生成更一致的性能基线。
智能处理工作负载变化
解决随使用量的增加、功能变化和数据随时间的累积而产生的性能下降问题，以维持性能。 如果微调仅带来短期好处，请重设预期并建立新的目标。
通过采用此方法，可以在性能降级之前保留性能状态，避免引发负面影响超出可接受范围的用户体验问题。
更改目标后会重设性能模型，并且你不会浪费时间优化已达到其容量的系统。
Contoso 的挑战
- 销售团队一直在积极地将新的活动场所加入到系统中。 生意很好。
- 工作负载监视系统已经开始注意到，即使没有引入新功能，性能预算也会随着时间而被消耗的越来越多。
- 如果不作更改，这种轨迹可能会导致性能发生不可接受的退化，使工作负载在发生事件时面临中断的风险。
应用方法和成果
- 该团队意识到，随着更多客户的加入，在线活动的数据查找机制正在对许多查询的数据执行非常大的扫描。
- 某些查询优化有助于防止使用量增加造成额外的伤害。 在接下来的几个月里，该团队计划将不同的活动分成不同的数据分区，以减少查询扫描的需求。 这将支持继续横向扩展工作负载。
- 他们还意识到，通过删除旧活动中的门票数据，可以进一步优化系统以便扩展。 搜索旧活动并不是门票验证系统需要执行的操作，因此可以将这些数据移动到专用于报告和历史查找的存储中。