ruby-on-rails - 作为持续集成构建周期的一部分，如何对 Rails 应用程序进行性能测试？

Question

我们目前为 CI 使用 CruiseControl(ruby 版本)，它运行我们的单元和集成测试(主要是 rspec)。

太好了:它为我们提供了有关任何功能问题或回归的即时反馈(我在近似意义上使用即时；-)。

它没有告诉我们的是我们的提交是否引入了性能回归。

如果测试测量到性能下降 5% ，我希望我们的构建变为 RED当然，我们也指出了这个问题，无论是响应不佳的数据库查询、花在 ruby​​ 函数或 Controller 响应上的时间。

连续性能测试是一个在过去几年中进行了一些讨论的话题，但除了一些供应商产品(主要针对 java 和 .NET 世界)之外，我在 Rails 方面看不到太多。我认为我们和大多数人一样:性能、负载和容量测试是一项单独的事件，通常在重大更新之前完成，但在例行迭代和发布期间经常被遗忘。而且我们只是因为 NewRelic 在监控我们的实时实例方面的出色表现以及一点点运气才让自己免于遇到重大麻烦。

CI 对于敏捷开发实践至关重要，并且缺乏持续的性能测试在构建期间似乎是我们工具中为数不多的几个大差距之一。

我会喜欢一些答案，这些答案可以指向任何可以提供帮助的工具，甚至可以体验你自己是如何破解这个问题的。注意:我们不喜欢 CC，也不反对在构建周期中包含其他(甚至是商业)产品，如果它们能够完成这项工作的话。

Answer 1

假设你已经看过这个:
http://guides.rubyonrails.org/performance_testing.html

另一方面，我们通过基于 Jenkins 的 CI 框架每晚运行基于 Grinder 的性能测试。请注意，它不是针对每个构建运行的，它每天晚上都是自动的，获取最新的构建(因此可能每 4 个构建左右。)在各种并发用户级别运行测试大约需要 4 小时，但我们可以显着缩短如果我们只是在单个用户级别运行。因为它是通过 Jenkins 运行的，所以如果指标不好，我们可以返回错误(使其变为 RED)，但我们还没有这样做。

如果您真的只是在寻找性能下降，那么对最新代码运行单个测试(衡量您关心的内容)并跟踪从构建到构建的历史响应时间应该可以为您解决。