如何使用新Relic的性能工程和负载测试

性能工程和负载测试是任何现代软件组织工具集的关键部分。事实上，看到公司实地专用负载测试团队和环境越来越常见 - 以及许多没有这样的过程的公司正在迅速发展。

通过驱动关键绩效指标（KPI），软件应用程序的性能工程和负载测试有三个主要目标：

1. 证明应用程序的当前能力
2. 确定应用程序代码，软件配置或硬件资源中的限制瓶颈
3. 增加应用程序对目标工作负载的可伸缩性

更具体地说，典型的负载测试可能如下所示:

虽然有大量工具可用于为性能测试生成用户负载，新的遗物平台（特别是新遗物APM那New Relic的基础设施,新的遗物浏览器）提供深入的监控和功能，可以对分析此类测试的重要洞察 - 从浏览器响应时间到用户会话以应用速度到使用后端资源的应用程序。借助新遗物的负载测试环境的团队将完整的端到端可见性进入其应用程序的性能。

此博客帖子显示了如何在性能工程过程中使用新遗物的规定的12步概述（分为3份），以便在性能工程过程中使用新的遗物进行方法负载测试和根本原因分析。

第1部分:设定基线并确定电流容量

第一步是设置负载测试并缓慢增加负载，直到您的应用到达瓶颈。

1.从最小用户加载开始（例如，5个并发用户），执行持续至少1小时的负载测试。这种低负载测试的结果将作为您的基线。

专家提示：如果您的基线负荷测试结果显示，交易超出您的服务水平协议（SLA），则没有理由进一步测试可扩展性。您可以继续下一步。

2.使用基线负荷测试结果，设置可接受的APDEX分数对于您的申请。APDEX将是您申请平均响应时间的仪表。创建关键交易对于执行时间长于整个SLA的特定事务。例如，对于典型的Web应用程序，浏览器APDEX值可能为3秒钟。Java应用程序的APM APDEX值可能为0.5秒。如果您的应用程序是通过API处理事务的MicroServices集合，则每个服务都可以为0.2秒。该想法是为执行事务的每个服务设置适当的ADEX。

3.设计并执行负载测试，有条理地增加用户数量。吞吐量和用户负载目标对每个应用程序都是唯一的。例如，您可以使用5个并发用户启动负载测试，并每15秒添加5个用户。随着用户数增加，您的负载测试将慢慢接近性能下降点，这将让您了解您的应用程序可以处理多少加载。

专家提示：在设计您的负载测试时是有条不紊的 - 不要将目标工作负载丢弃到应用程序上，或者您将留下难以解释的混沌结果。因此，例如，如果您的目标是达到5,000个并发用户，请设计负载测试以达到目标的一半。如果应用程序将成功缩放到无与止的目标负载，则继续并设计下一个测试以加倍负载。

此外，如果您是在负载测试吞吐量而不是用户或活动会话，您仍然可以使用相同的方法来实现每秒事务的目标数量。例如，如果您的API的吞吐量目标是每秒200个事务，那么就从一个可以扩展到每秒100个事务的负载测试开始。

4.在应用程序的APM概述页面中，更改视图以查看Web事务百分比并浓缩95％的线，95％比中位或平均值更敏感和粒度。

在负载测试开始降低之前，突出显示并放大时间范围。从此时间跨度来看，您可以执行更深入的分析（例如，进入事务迹线，分布式迹线和错误），或从APM切换到浏览器（用于前端分析），新遗物自动保持焦点的孤立的时间范围。

专家提示：该测试的关键部分是识别的第一个瓶颈。您不需要担心在第一个弯曲点之后图表中会发生什么，任何超过这个点的东西都只是一个症状，您应该将其与根本原因区分开来。

第2部分：分离第一个瓶颈

当您对性能下降进行故障排除时，以何种顺序执行下面的步骤5-9，这在您的情况下最有意义。例如，您可以通过分析响应时间来开始新的遗物浏览器并向后向后工作，直到您在APM中识别代码缺陷（自上而下的方法）。或者你可以开始New Relic的基础设施识别导致浏览器响应时间较差的资源限制(一种自底向上的方法)。

5.使用步骤4中收集的信息，使用服务地图确定内部或外部服务正在降级和导致总体响应时间的申请交易。

专家提示：如果您在劣化的多项交易中看到任何趋势，通常表示某些资源正在接近其饱和点。

6.使用新的遗物APM逐步隔离代码缺陷或错误条件。采用交易痕迹隔离劣化或抛出错误的确切代码。

7.使用基础设施的主机集成确定基础架构中的任何限制，例如Web服务器，JVM或数据库。

8.使用基础架构在应用程序部署中检查每个主机/服务器，以查看是否有过度使用的硬件资源（CPU，内存，网络等）。

专家提示：硬件资源不一定要完全饱和才能降低响应时间—即使70%的饱和也会导致性能问题。

但是如果您在负载测试中识别的瓶颈不是硬件资源，请检查服务器的软件资源，包括连接池，数据源连接及其TCP堆栈。当软件资源饱和时，他们通常会在基础设施中显示为“排队”。

9.使用浏览器来确定是否有任何增加的响应时间源自应用程序前端。例如，当您的网站需要渲染HTML资产时，是ajax.请求第三方远程服务器导致放缓？

第3部分：调整以缓解瓶颈

一旦确定瓶颈的原因，部署新的更改并恢复负载测试。

10.对应用程序部署进行必要的更改，并设置一个新的遗物部署标记记录变更。标记此部署标记与变更的详细信息（例如，“添加了2个CPU至VM”）。

专家提示：一次只改变一个变量。如果同时更改2个或更多内容(例如，如果添加更多硬件资源并将JVM堆大小增加一倍)，就会混淆每个变量对应用程序总体负载的影响。

11.重新运行第1部分的负载测试并分析结果。确定结果是否相同，更好或更差 - 没有差异意味着您没有识别正确的瓶颈。保留或恢复您的更改（必要时重复上一步）。

12.继续负载测试过程，消除它们发生的瓶颈，直到满足您的负载需求。

保持前进工程是一个迭代过程

负载测试和性能工程永远不会“完成”。您的应用程序部署的每个组件，从其工作负载到其架构的功能，正在不断发展。因此，一旦建立了一个现实的性能测试，就不要改变它只是为了改变它。作为重新配置测试的运行时设置的东西可以完全偏斜结果，下次运行它。在应用程序应保持变量时，性能测试应保持常量。

额外的负载测试和性能分析资源

最后，以下是一些其他新的遗物工具，可以方便地掌握有条件的负载测试和性能分析：

• 服务地图：确定应用程序部署中服务之间的连接和上游/下游依赖项。
• 分布式追踪：清楚地了解您在应用程序中的交易横向服务的图片。
• 仪表板：跟踪KPI的您有兴趣在使用灵活的交互式可视化期间在负载测试期间观看。