5 个快速的 Node.js 应用性能提示

本系列文章涵盖许多基础性内容：它给出了应用程序性能管理（APM）的总体概述；指明了实现一个 APM 策略的主要挑战；提出了衡量，评估一个企业级 Node.js 应用程序运行状况的最重要的 5 条指标；并提出了通过 AppDynamics 方式构建一个 APM 解决方案。在文章的最后部分，还提出了一些提示和技巧类以帮助您实现最佳的 APM 策略。具体地说，本文讨论了以下主题：

• 业务交易优化

• 快照调优

• 阈值调优

• 层级管理

• 上下文信息捕获
   

1.业务交易优化

本文章系列里，我会不断重复强调的就是监控方案里的业务交易优化一环。要最有效地利用业务交易监控，您需要做到以下几项：

• 恰当地命名业务交易以配合您的业务功能

• 正确识别您的业务交易

• 通过排除您并不关心的业务交易来降低噪音

AppDynamics 可以为您自动识别业务交易，并且尽可能给出最优的命名。不过这样取决于您的应用是如何编写的，应用名可能可以如实反映业务交易，也可能不可以。例如，您可能有一个业务交易叫做“POST/payment”，对应着检验流程。那么如果将其命名为“Checkout”的话，就更能如实反映业务功能，这将更利于操作人员操作，也便与生成报表与执行人员查看。

下面，如果您有多个业务交易，却只有一个入口的话，你需要花一些时间将其分割为独立的业务单元。以下几个可能发生的例子，包含如下特点：

•  多个 URL 都路由到相同的 MVC 控制器和动作

• 根据有效负载的制定业务交易功能

•  根据 GET 参数制定业务交易功能

•  复杂的 URL 路径

如果一个入口却对应着多个业务功能，那么就需要根据不同的指标配置业务交易。例如，如果 body 里有一个”operation“元素对应着”operation“操作的话，那么就需要根据”operaiton“对交易进行分割。又如果有一个”execute“动作接受一个”command“URL 参数，那么就需要根据”command“字段对交易进行分割。最后，URL 模式可能会因应用不同而不同，所以您需要与您的应用最匹配的形式。例如，AppDynamics 会根据两段式自动为您的 URL 定义业务交易，例如 one/two。大多数 Node.js MVC 框架都会自动路由到对应的应用控制器和动作。如果您的应用使用的是一段式，或者四段式，那么您需要根据命名规则来定义业务交易。

命名和识别业务交易单元可以确保您捕捉到了正确的业务功能，但是尽可能多的减噪也同样重要。您是否有些并不关心的业务交易呢？比如，会不会有一个网页游戏会每隔几秒就检查对高分呢？又或者如果有一个每晚都执行的 Node.js 的 CLI 作业，每次都执行很长时间，但是由于脱机运行，它并不影响终端用户，您不关心么？ 如果是的话，排除这些交易，以便减少分析噪音。

2. 快照调优

正如在前面文章提到的，AppDynamics 每隔一段时间就会智能捕获性能快照，并可以逐渐缩小每次性能会话里快照的个数。由于这两个值都是可以调整的，所以有利于调优。

AppDynamics 直接捕获整个进程的调用关系图，同时去掉配置阈值以下的记录。如果你只对“大的”性能问题感兴趣，那么你可能不需要精确到 10 毫秒以下。如果你把间隔时间增加到 50 毫秒，你会丢失粒度。如果你想微调应用程序，你可能需要 10 毫秒的粒度，但是如果你不打算让方法在 50 毫秒内执行完毕，为什么需要那种级别的粒度呢？问题在于你应该分析需求然后做相应的调整。

接下来，观察你的产品故障排除模式，然后判断 AppDynamics 捕获的进程快照数在你当前状况下是否合适。如果你发现每分钟捕获 2 个快照太多了，那么你可以配置 AppDynamics 来调整快照间隔。尝试配置 AppDynamics 让其每分钟最多捕获一个快照。另外如果你只对系统性问题感兴趣，你可以把最大快照数降低至 5 个。这会显著地减少持续的消耗，但代价是可能会导致捕捉不到有代表性的快照。

如果您的应用程序的响应时间不稳定,那么默认的两个标准差临界值可能导致太多的错误警报。在这种情况下，您可能希望增加更多的标准差或换一种方式来处理。如果您的应用程序的响应时间比较稳定，你就会想减少你的临界值提前发出警告。此外，如果你有提供给特殊协定用户的服务或 API（应用程序接口），你应该为此业务设置一个稳定的协定值。AppDynamics（应用性能管理）会提供给你个人或企业业务定义警报规则的灵活性。

你需要分析你的应用程序的行为，并相应地配置报警引擎。

如果在你的系统中，所有的 service 调用都使用的是通用协议栈（比如 HTTP 协议）， 那么 AppDynamics 将非常完美的分析出你的系统的服务层次，但是如果你的系统使用了一个非通用协议栈和后端系统进行通信，AppDynamics 就无能为力了。举例来说，目前我在一个保险公司工作，这个保险公司使用一个 AS/400 机器提供询价服务。在我们的系统中，我们使用了一个私有库来和 AS/400 通讯，这个库使用了一个私有的基于 socket 的通讯协议链接到 AS/400 上。在这种情况下，很明显 AppDynamics 不可能知道系统使用了基于 socket 的通讯协议，也不可能知道这 个socket 通讯协议是如何工作的。因此，我们需要告诉 AppDynamics 是哪个方法实现了和 AS/400 之间的通讯，并且标记这个方法为定制化的后端资源。这样一来，AppDynamics 就会将这个方法识别成一个新的服务层次，接下来 AppDynamics 就可以对这个新的服务层次进行调用计数，并计算它的平均响应时间了。

在大部分情况下，你可以使用 AppDynamics 的内置功能来分析系统的服务层次，但是如果你有特定的要求，AppDynamics 也提供了 Node.js API，让你自己定义系统的服务层次。

你可以通过配置让 AppDynamics 获取上下文信息并且加入到快照中，可以被捕获的上下文信息在上一节中已经详细介绍了。下面我们简单的介绍一下 AppDynamics 获取上下文信息的过程：

1. AppDynamics 发现了一个运行缓慢的业务事务

2. 于是 AppDynamics 开始创建一个快照

3. 在创建快照的过程中，AppDynamics 根据你配置的信息，获取相应的上下文信息并放入快照中

结果就是当你找到一个可以反映你试图解决的问题的快照的时候，你可以在 AppDynamics 为你捕获的上下文信息中查看是否有有用的信息。

当你使用上下文信息捕获功能的时候，因为 AppDynamics 使用侵入式代码来获取方法的参数值，这将造成原始代码运行效率有一些下降。因此，只在确实需要的地方使用这个功能。