我们目前使用CruiseControl（ruby版本）进行CI，它运行我们的单元和集成测试（主要是rspec）。
这很棒：它为我们提供了有关任何功能问题或回归的即时反馈（我在近似意义上使用即时 ;-)。
它没有告诉我们的是我们的提交是否引入了性能回归。
如果测试结果表明性能降低了5％，我想让我们的构建变为RED。当然，我们会指出这个问题，无论是对数据库查询的响应能力差，还是花在红宝石功能或控制器响应。
持续性能测试是一个在过去几年中进行过一些讨论的主题，但除了一些供应商产品（主要针对java和.NET世界）之外，我在Rails方面看不到太多。我认为我们最像：性能，负载和容量测试是一项单独的活动，通常在重大更新之前完成，但在常规迭代和发布期间经常被遗忘。而且我们只能让自己摆脱重大麻烦，因为NewRelic在监控我们的实时实例方面非常棒，而且还有一点运气。
CI对于敏捷开发实践至关重要，并且在构建过程中缺乏持续的性能测试似乎是我们工具中为数不多的差距之一。
我希望得到一些答案可以指出任何可以提供帮助的工具，甚至可以体验你自己如何破解这些工具。注意：我们不会与CC结婚，也不反对在构建周期中包含其他 - 甚至是商业产品 - 如果他们能够做到这一点。
答案 0 :(得分：1)
假设你已经看过这个： http://guides.rubyonrails.org/performance_testing.html
另一方面，我们通过基于Jenkins的CI框架运行每晚一次基于Grinder的性能测试。请注意，它不是针对每个构建运行的，它每晚都是自动的，抓取最新版本（所以它可能每4个版本左右。）大约需要4个小时来完成各个并发用户级别的测试，但我们可以大大缩短如果我们只是在一个用户级别运行。因为它是通过Jenkins运行的，如果指标不好，我们可能会返回一个错误（让它变为RED），但我们还没有这样做。
如果您真的只是在寻找性能下降，在最新代码上运行单个测试（测量您关心的内容）并跟踪从构建到构建的历史响应时间应该为您完成。