【.com快译】性能工程（Performanceengineering）和压力测试（loadtesting）是任何现代软件组织日常工作中非常关键的组成部分。事实上，许多公司正在越来越多地投资建设这样的团队。缺乏此类流程的公司正在朝着这个方向迅速改进。从理论上讲：在关键性能指标（KPI，参见：https://kpi.org/KPI-Basics）的驱动下，软件应用领域的性能工程和压力测试主要有以下三个目标：1.验证当前负载能力的应用程序。2.确定应用程序代码、软件配置和硬件资源方面的瓶颈。3.提高应用程序的可扩展性以满足目标负载能力。具体来说，一个典型的压力测试涉及以下六个方面：目前，虽然业界有大量的相关测试工具，但它们可以通过产生非用户，而是NewRelic平台的访问负载来进行性能测试，尤其是NewRelicAPM(https://newrelic.com/products/application-monitoring)、NewRelic基础设施(https://newrelic.com/products/infrastructure)和NewRelic浏览器(https://newrelic.com/products/browser-monitoring）提供更深入的监控和服务，以及各种关键洞察。NewRelic可以分析浏览器响应时间、用户会话数、应用程序速度和后端资源利用率。基于NewRelic创建的压力测试环境，测试团队能够获得应用程序性能的端到端“全景图”。本文将分为3个部分12个步骤向大家介绍如何在性能工程中使用NewRelic进行有序的压力测试和规范的根因分析。第1部分：基线和确定当前容量？我们的首要任务是构建压力测试并慢慢增加负载，直到应用程序出现瓶颈。1、我们从最小用户数的负载开始（例如：5个并发用户），进行至少1小时的压力测试。我们使用这个低负载测试的结果作为基准。如果根据基线压力测试的结果，并发交易已经超过服务水平协议（SLA），那么我们没有理由进行进一步的可扩展性测试。如果一切正常，我们将继续下一步。2.通过基线压力测试的结果，可以为应用设置可接受的Apdex分数（https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measure-user-满意）。Apdex是目标应用程序平均响应时间的度量。您需要为执行时间超过总体SLA的特定交易创建关键交易(https://docs.newrelic.com/docs/apm/transactions/key-transactions/introduction-key-transactions)。例如，对于一个典型的Web应用程序，其BrowserApdex值应为0.3秒。Java应用程序的APMApdex值可能为0.5秒。如果您的应用程序有一组微服务并通过API处理事务，那么每个服务的Apdex可能是0.2秒。因此，我们的目标是为每个交易执行服务设置一个合适的Adex值。3.设计并执行压力测试，然后有条不紊地增加用户数量。为每个应用程序设计不同的吞吐量和用户负载目标。例如，您可以触发5个并发用户的压力测试，然后每15秒再添加5个用户。随着用户数量的增加，压力测试会慢慢接近性能的临界点，这会让你了解目标应用程序可以处理的负载极限。切记：压力测试应该设计成按顺序进行，而不是一次性将目标工作负载扔到应用程序上，否则结果会混乱且难以解释。例如：如果您的目标是达到5,000个并发用户，那么您应该设计压力测试以首先锚定该目标的一半。如果应用程序可以成功扩展到目标负载的一半，那么您可以继续设计下一轮测试以将负载加倍。同样，如果您正在测试负载吞吐量而不是用户与活动会话，您仍然可以使用相同的方法稳健地达到每秒的目标事务。例如，如果您的API吞吐量目标是每秒200个事务，那么您可以逐渐将测试压力扩大到每秒100个事务。4.在应用程序的APM概览页面中，您可以通过更改视图来查看“Web事务百分位数”。由于95%的记录会比中值或平均值更清晰、更详细，因此您可以专注于这95%的记录行。通过观察，您可以找到目标应用在压力测试下开始出现服务下降的时间点，然后突出显示并放大该时间范围和跨度，以便您进行更深入的分析。例如，您可以深入挖掘各种事务性、分布式痕迹和相关错误，或者从APM模式切换到Browser模式，从前端转换到后端分析。NewRelic可以在这个时间范围内连续自动地关注各类信息。请记住：此测试部分的主要目标是首次识别瓶颈，因此您无需担心第一个拐点之后的图表移动。超出该点的任何情况都只是潜在原因的后续症状。第二部分：隔离第一个瓶颈对于上面发现的性能下降，可以根据应用的实际情况，执行下面的5-9步（不一定按这个顺序）来排查问题。例如，您可以先使用NewRelicBrowser分析响应时间，然后逐步查找APM中的代码缺陷（即所谓的自上而下方法）。当然，您也可以从NewRelicInfrastructure入手，找出那些使浏览器响应耗时的资源限制（即所谓的自底向上方法）。5.利用第4步收集到的信息，使用服务地图（servicemaps，https://docs.newrelic.com/docs/understand-dependencies/understand-system-dependencies/service-maps/introduction-service-maps）来确定哪些应用程序交易的内部和外部服务水平下降并导致整体响应时间增加。如果您看到多个事务的服务级别下降，通常表示某些资源正在接近其饱和点。事务分析6.使用NewRelicAPM逐步隔离各种代码缺陷或错误情况。使用事务跟踪(https://docs.newrelic.com/docs/apm/transactions/transaction-traces/introduction-transaction-traces)来隔离使服务降级或引发错误的确切代码。7.使用Infrastructure的主机集成（on-hostintegrations，https://docs.newrelic.com/docs/integrations/host-integrations/getting-started/introduction-host-integrations）识别Web服务器、JVM或数据库限制。8、使用Infrastructure检查应用部署中涉及的每一台主机和服务器，看是否有硬件资源（CPU、内存、网络等）被滥用。硬件资源不必完全饱和就会导致响应时间增加。有时，当它达到70%的饱和度时，它的性能就会受到影响。如果在压力测试中发现瓶颈不是来自于硬件资源，那么请检查服务器的软件资源，包括：连接池、数据源连接数、它的TCP栈。因为当软件资源变得饱和时，它们也会在基础设施中“排队”。9.使用浏览器确定响应时间的增加是否来自应用程序的前端。例如，当您的网站需要呈现某些HTML资产时，发送到第三方远程服务器的Ajax请求数量可能会导致整体速度下降。第3部分：优化以缓解瓶颈确定瓶颈的原因后，您需要通过实施更改来应对新的压力测试。10.对于应用的任何改动，都需要设置NewRelic的部署标记（deploymentmarker，https://docs.newrelic.com/docs/apm/new-relic-apm/maintenance/record-deployments）来赋予它记录。您可以使用诸如“向VM添加2个CPU”等详细信息标记部署以进行更改。记住：一次只修改一个变量。如果一次修改两个或更多的东西（例如，添加多个硬件资源和将JVM堆栈的大小加倍），那么您将无从得知是哪个变量影响了应用程序的整体加载性能。11.重新运行压力测试并分析新结果以查看性能是否有所改善。如果没有区别，那就意味着你还没有找到真正的瓶颈。请保留或还原之前的更改，并根据需要重复之前的测试步骤。12、继续进行压力测试，直到瓶颈真正消除，满足既定的负载要求。让性能工程成为一个迭代的过程客观来说，压力测试和性能工程是“永无止境”的。由于架构中几乎每个组件都在持续开发和部署，从应用程序工作负载，到功能服务，再到架构中的几乎每个组件，即使是一个简单的新更改也可能对初步性能测试结果产生重大影响。因此，性能测试应该随着应用程序的迭代而继续进行。额外的压力测试和性能分析资源以下是一些其他类型的NewRelic工具，您可能会发现它们对压力测试和性能分析很有用：服务映射(https://docs.newrelic.com/docs/understand-dependencies/understand-system-dependencies/service-maps/introduction-service-maps)：应用部署时，可用于识别服务与上下游依赖关系的连接。DistributedTracing(https://docs.newrelic.com/docs/apm/distributed-tracing/getting-started/introduction-distributed-tracing)：一种横向服务，方便用户清楚地了解应用程序中的不同事务。Dashboards(https://docs.newrelic.com/docs/dashboards/new-relic-one-dashboards/get-started/introduction-new-relic-one-dashboards):在压力测试过程中，通过灵活的交互，直观地跟踪用户感兴趣的那些KPI。原标题：HowtoUseNewRelicforPerformanceEngineeringandLoadTesting，作者：RebeccaClinard
