New Relic 作为一个“软件即服务（ SaaS ）”，为 Rails 提供性能监视和分析服务。我们访问了 New Relic 的作者 Lew Cirne，来谈一谈这项技术是如何工作的。
InfoQ: 你是怎样实现性能监视功能的？它对性能有什么影响吗？它能不能运行在非 MRI 的 Ruby 版本上？
我们的工具是用 100% 的 Ruby 代码写的，因此可以运行在所有的硬件 / 操作系统组合上的任何的 Ruby 环境中，也能用在所有的 Ruby VM 实现上，包括 JRuby 和 Rubinius 等。基于 Ruby 的动态语言特性，我们把轻量级的“跟踪器”放置在相对重量级的操作上，比如控制器行为、 ActiveRecord 查询等。 这个方法虽然相对简单，但是要做好其实很难。幸运的是，我们具有相关的资深经历。我们做过 Wily Technology 公司的 Introscope，这是一个行业领先的用于企业级 Java 平台的应用程序性能管理方案。因此，尽管可能有一些虽使用这个方 法却写得很差的软件会对应用程序的性能和稳定性产生影响，而我们的则不会。测试表明，我们只会给每一个事务的响应时间增加 2~5 毫秒，而且我们的 CPU 消耗也很低（远低于 5％）。可我们却提供了极其丰富的性能数据来近乎实时地显示出应用程序正在做什么。
由于我们不分析事后的日志文件，因此就有一些益处：我们可以更快地报告这些数据（每分钟一次），并且保持低消耗和零磁盘 /IO 操作——我们能得到很深的能见度，而且能 见度也很容易定制——如果是一个 Ruby 方法，我们还可以跟踪它——在产品机上则没有任何额外的部署、维护和消耗资源的过程。我们有 50 个客户在使用内部 测试版的 RPM——它们中许多都是大规模的 rails 网站——而没有一个客户在使用我们的工具时遇到过任何问题。
InfoQ: New Relic 应该说是作为“软件即服务”来工作的——这是如何实现的呢？是不是把收集到的信息通过网络发送到你的服务上呢？
我方才介绍的这个工具是这样工作的：它每分钟把收集到的性能数据通过 http 或 https（取决于用户选择）报告给 NewRelic.com。这些数据被呈现为一组非常直观的视图，来回答一个活动 rails 应用程序的常见性能问题，例如：
- 最慢的控制器行为有哪些？
- 它们的性能是怎样随时间变化的？
- 一个特定的控制器行为的响应时间是怎样中止的？
- 哪些 ActiveRecord 对象最常被查询或者被保存？最慢的 ActiveRecord 查找有哪些？
- 我有没有丢失一个索引（index）？
InfoQ: 目前 New Relic 能识别哪些性能问题并给出报告？能发现错误代码实践、丢失缓存等等吗？
这两个都是非常好的例子。还有一个例子我们也经常看到，就是应用程序在一个紧密的循环里引发了大量的（可能是很快的）活动记 录操作，这就给数据库带来了很大的负担。数据库工具报告说它运行得很好，而实际上程序却可能由于查询做得不够好而在滥用数据库。我们也跟踪由控制器行为导 致的缓存使用，这也是高性能和大规模 rails 站点上的一个公共的焦点问题。
InfoQ: 你提到了 New Relic 的一个用户—— Lighthouse ——有没有其他客户的名单？
尽管我们仍处于内部测试阶段，可我们已经有了大量的客户，他们中很多都是 rails 社区的“名人”。Lighthouse 就 是个很好的例子——Rick Olson 是 Ruby on Rails 平台的核心开发者之一，也是 rails 社区的一个多产的贡献者。我认为他的认可意义非凡。 登记在案的其他客户中还包括 New Relic 的粉丝们，比如 Moku Gift（推出了 E-Tree，而且他们还种了一棵真的！）、Redeparede.com（面向非英语市场的社会化网络），以及 Hutz.com（度假 房屋租赁商场）。期待我们的客户能在不久的将来给予我们更多的认可。
InfoQ: 你打算用什么样的许可模式？采用怎样的价格策略？
我们还没有公布价格。但是当我们公布时，你会发现 RPM 会采用订阅式的（subscription-based ）收费服务。客户将按月支付与他们的管理环境相对应的费用。
RubyInside 也报道了 New Relic ，提到 New Relic 公司最近获得了一笔 350 万美元的风险资本融资，还指出了另一个性能监视方案： FiveRuns 的 RM-Manage 。
获得关于 Rails 应用程序性能的信息，可以看看 James Cox 关于“管理高性能 Rails 应用程序而不必抓狂”的讲座。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论