在Salsify，我们大部分基于Ruby on Rails的基础架构都是在Heroku上运行的。我们最近换了彪马从Heroku 2X dynos到更强大的HerokuPX绝妙的并且看到了显著的性能改进:平均响应时间减少了51%，响应时间减少了59%，减少了99%。基于此，我们进行了一些运行内存/CPU密集型的实验拖延工作在PX dynos上，平均作业执行时间减少了43%，99%的作业执行时间减少了66%。这对于概念验证来说是很棒的，但PX dyno上的8个核心中只有一个被使用了。为了以一种低成本的方式将其投入生产，我们必须想出如何利用所有的核心功率计。

大多数Rails开发人员很快就学会了通过正确指定来最小化数据库查询的数量急切的负载对于良好的应用程序性能至关重要。不幸的是，指定预先加载很容易出错，并可能导致封装问题。在这篇文章中，我们将探索让Rails自动处理急切的负载。

在Salsify，我们写了很多水豚这些测试是基础架构的关键部分，使我们能够快速移动和重构而不破坏任何东西。不幸的是，随着我们添加越来越多的测试，在拆除测试时，我们开始遇到零星的挂起和数据库死锁。经过一些调查，我们发现问题是在测试分解过程中，我们的JavaScript客户端向Rails服务器发出AJAX请求。这篇文章详细介绍了我们消除这些问题并使测试再次可靠运行的过程。

以前我们在博客中讨论了在Rails中使用数据库视图进行快速加载计算，以避免运行大量的数据库查询。我们所描述的方法只有在SQL相当静态且不介意为每次计算创建数据库视图时才有效。在这篇文章中，我们将探索一种替代方法，通过不使用数据库视图来避免这些问题。首先让我们快速回顾一下这个问题……

更新:这篇文章中讨论的插件已经被打包到delayed_job_heartbeat_plugin宝石。

之前我们曾在博客上讨论过如何写“延迟的工作”插件以及如何将工作汇总成工作小组．在这篇文章中，我们将探索如何主动检测失败的延迟工作人员，以便他们的工作可以及时重试。当一个worker崩溃、被平台提供者自动重启或被自动伸缩的基础设施关闭时，这是非常有用的。

最近，我在博客上写了一篇关于“被耽搁的工作”的文章插件机制．在这篇文章中，我们将探索如何使用这个插件机制将作业组添加到Delayed job中，使我们能够:

婆罗门参是一个单页面应用程序(客户端是Backbone，后端是Rails + Postgres + Elastic Search)，需要非常低的响应延迟来提供浏览和编辑产品目录的交互体验。为了满足这些延迟需求，我们非常依赖拖延工作用于运行耗时的任务，如导入数据、导出数据和在后台进程中应用批量更新。我们发现了使用延迟工作回调的有用模式钩子我想和大家分享