最后几篇文章介绍了应用程序性能管理 (APM)，并确定了有效实施 APM 策略的挑战。本文以这些主题为基础，通过回顾五个要捕获的顶级性能指标来评估您的企业 PHP 应用程序的健康状况。
这篇文章具体评论了以下内容：
- 商业交易
- 内部依赖
- 外部调用
- 缓存策略
- 应用拓扑
1. 商业交易
业务事务提供对真实用户行为的洞察：它们捕获真实用户在与您的应用程序交互时所体验的实时性能。如上一篇文章所述，衡量业务事务的性能涉及全面捕获业务事务的响应时间以及衡量其组成层的响应时间。然后可以将这些响应时间与最能满足您的业务需求的基准进行比较，以确定是否正常。
如果您只想衡量应用程序的一个方面，我建议您衡量业务交易的行为。虽然容器指标可以提供大量信息并可以帮助您确定何时自动扩展您的环境，但您的业务交易决定了您的应用程序的性能。与其询问您的应用程序服务器的 CPU 使用率，不如询问您的用户是否能够完成他们的业务交易以及这些业务交易是否正常运行。
作为一个小背景，业务事务由它们的入口点标识，这是与启动业务事务的应用程序的交互。对于 PHP 应用程序，这通常是 HTTP 请求。可能有一些例外，例如 PHP CLI，在这种情况下，业务事务可能是由 cron 作业从命令行执行的 PHP 脚本。在 PHP 工作服务器的情况下，业务事务可能是 PHP 应用程序执行的作业，它从队列服务器中获取。或者，您可以选择为基于 URL 参数的同一 Web 请求或基于其正文内容的服务调用定义多个入口点。关键是业务交易需要与对您的业务有意义的功能相关。
一旦确定了业务事务，就会在整个应用程序生态系统中衡量其性能。每个单独的业务交易的性能都根据其基准进行评估，以评估正常性。例如，我们可能会确定，如果业务事务的响应时间比该基线的平均响应时间慢两个标准差，则表明它的行为异常，如图 1 所示。
图 1 根据其基线评估 BT 响应时间
用于评估业务交易的基线在业务交易运行的那一小时内是一致的，但是业务交易正在被每个业务交易执行细化。例如，如果您选择了一个基线来将业务交易与一天中某个小时和一周中某天的平均响应时间进行比较，则在当前小时结束后，该小时内执行的所有业务交易都将被纳入基线下周。通过这种机制，应用程序可以随着时间的推移而发展，而无需丢弃和重建原始基线；您可以将其视为随时间移动的窗口。
总之，业务交易是最能反映用户体验的衡量标准，因此它们是要捕获的最重要指标。
2.内部依赖
您的 PHP 应用程序可能正在使用后端数据库、缓存层，甚至可能是队列服务器，因为它将 I/O 密集型阻塞任务卸载到工作服务器上以在后台处理。无论您的 PHP 应用程序与哪个后端接口，这些后端服务的延迟都会影响您的 PHP 应用程序的性能。各种类型的内部退出调用可能包括：
- SQL数据库
- NoSQL 服务器
- 内存缓存
- 内部服务
- 队列服务器
在某些环境中，您的 PHP 应用程序可能与模糊的后端或消息/队列服务器进行交互。例如，您可能有一个旧的消息代理作为您的 PHP 应用程序和其他应用程序之间的接口。虽然此消息代理可能已过时，但它仍然是旧架构的一部分，并且是分布式应用程序与之通信的生态系统的一部分。即使您的 APM 解决方案不会自动发现消息传递服务器，您也可以构建额外的工具来检测消息传递服务器并测量延迟。如果您想绘制相关性以便业务事务不会变得支离破碎，您还可以构建额外的检测，以便在请求通过消息传递服务器传递到队列另一端的应用程序时自动完成相关性。
从业务交易的角度来看，我们可以将内部依赖性识别和度量为在它们自己的层中。有时我们需要配置监控解决方案来识别真正包装外部服务调用的方法，但对于常见的协议，如 HTTP 和 CLI，可以自动检测内部依赖关系。与业务交易及其组成的应用程序层类似，外部依赖行为应该是基线，响应时间应该根据这些基线进行评估。
无论您的 PHP 应用程序如何与内部服务进行通信，等待响应的延迟都可能会影响您的应用程序的性能和您的客户体验。如果您的通信可以帮助解决这些瓶颈，则测量和优化响应时间。
3.外部调用
除了您的内部服务和后端之外，退出调用还可能包括您的应用程序实时调用的远程第三方 Web 服务 API。例如，如果您的客户试图购买购物车中的商品，并且为了完成交易，您的应用程序必须从他们的信用卡中扣款，以便您可以显示确认或错误页面。这是一个阻止退出调用的示例，因为您的整个交易现在取决于对正在向信用卡收费的第三方商家提供商发出的该调用的响应。如果客户的信用卡收费成功，则会向用户显示确认页面和收据。如果信用卡被拒绝，则会向用户显示错误消息以重试。无论如何，客户正在等待依赖于第三方商家提供商的应用程序。退出调用的延迟将对该特定实例的性能产生直接影响。
外部依赖项可以有多种形式，是您的应用程序与之交互的系统。我们不一定能控制在外部依赖项内部运行的代码，但我们通常可以控制那些外部依赖项的配置，因此了解它们何时运行良好以及何时运行不良很重要。此外，我们需要能够区分应用程序中的问题和依赖项中的问题。
业务事务为您提供应用程序性能的最佳整体视图，并可以帮助您对性能问题进行分类，但外部依赖项会以意想不到的方式显着影响您的应用程序，除非您正在观察它们。
4. 缓存策略
从内存中为对象提供服务总是比通过网络调用从数据库等系统中检索对象更快；缓存提供了一种在本地存储对象实例以避免这种网络往返的机制。但是，如果缓存配置不当，它们可能会带来自身的性能挑战。常见的缓存问题包括：
- 将太多数据加载到缓存中
- 缓存大小不正确
在衡量缓存的性能时，您需要确定加载到缓存中的对象数量，然后跟踪这些对象被使用的百分比。要查看的关键指标是缓存命中率和从缓存中弹出的对象数。高速缓存命中计数或命中率报告从高速缓存提供的对象请求的数量，而不是需要网络访问来检索对象。如果缓存很大，命中率很小（低于 10% 或 20%），并且您没有看到很多对象从缓存中弹出，那么这表明您正在向缓存中加载过多数据。换句话说，您的缓存足够大，不会抖动（见下文）并且包含大量未使用的数据。
衡量缓存性能时要考虑的另一个方面是缓存大小。缓存是否像前面的示例一样太大？缓存太小？或者缓存大小是否合适？
调整缓存大小时的一个常见问题是没有正确预测用户行为以及缓存的使用方式。让我们考虑配置为使用 32M 内存的 APC 缓存。如果 32M 不足以让 APC 用作操作码缓存，那么您将面临将内存中的数据交换为磁盘上的数据的风险。考虑到磁盘 I/O 比从内存读取慢得多，这违背了内存缓存的目的，并显着降低了应用程序的性能。结果是我们花更多的时间来管理缓存而不是服务对象：在这种情况下，缓存实际上是在阻碍而不是提高性能。
当您将缓存设置得太小并发生上述行为时，我们说缓存正在抖动，在这种情况下，没有缓存几乎比抖动缓存更好。图 2 试图以图形方式显示这一点。
图 2 缓存抖动
在这种情况下，应用程序从缓存中请求一个对象，但找不到该对象。然后它通过网络查询外部资源以获取该对象并将其添加到缓存中。最后，缓存已满，需要选择一个对象从缓存中弹出，为新对象腾出空间，然后将新对象添加到缓存中。
5. 应用拓扑
在此前 5 名列表中要衡量的最后一个性能组件是您的应用程序拓扑。由于云的出现，应用程序现在可以具有弹性：您的应用程序环境可以扩大和缩小以满足您的用户需求。因此，对您的应用程序拓扑进行清点以确定您的环境大小是否达到最佳非常重要。如果您有太多的虚拟服务器实例，那么您的云托管成本将会上升，但如果您没有足够的虚拟服务器实例，那么您的业务交易将会受到影响。
在此评估期间衡量两个指标很重要：
- 业务交易负载
- 容器性能
业务交易应该是基线的，你应该知道在任何给定时间满足你的基线所需的服务器数量。如果您的业务事务负载意外增加，例如超过正常负载标准差的两倍，那么您可能需要添加额外的服务器以满足这些用户。
另一个要衡量的指标是容器的性能。具体来说，您想要确定是否有任何服务器层受到胁迫，如果是，您可能希望向该层添加额外的服务器。跨层查看服务器很重要，因为单个服务器可能由于垃圾收集等因素而处于胁迫状态，但如果层中的大部分服务器处于胁迫状态，则可能表明该层无法支持负载它正在接收。
因为您的应用程序组件可以单独扩展，所以分析每个应用程序组件的性能并相应地调整您的拓扑非常重要。
结论
本文介绍了您在评估应用程序运行状况时可能想要衡量的前 5 个指标列表。总之，前 5 项是：
- 商业交易
- 外部依赖
- 缓存策略
- 退出呼叫
- 应用拓扑
在下一篇文章中，我们将把本系列的所有主题放在一起，介绍 AppDynamics 实施其 APM 战略所采用的方法。这不是一篇营销文章，而是解释为什么要做出某些决策和优化，以及它们如何为您提供有关虚拟或基于云的应用程序健康状况的强大视图。