ruby-on-rails - Heroku 排队时间

Question

昨天我对我的 Rails 应用程序进行了负载测试，运行 8 个 dyno，每个上都有 3 个并发 Unicorn 进程。这是 New Relic 输出：

如您所见，我的 Rails 堆栈本身具有相当好的响应时间（DB、Web 等），但排队时间非常糟糕。

我能做些什么呢？这是 Heroku 性能固有的，还是仅仅意味着我需要添加更多测功机？

任何建议表示赞赏。

Answer 1

基本上，将问题分解成各个部分并测试每个部分。简单地向独角兽集群抛出一堆请求不一定是衡量吞吐量的好方法。您必须考虑许多变量（旁注：查看Zed Shaw的“程序员需要学习统计数据，否则我将杀死他们”）

此外，您正在从问题中遗漏关键信息以解决谜题。

• 每个独角兽每秒处理多少个请求？
• 总测试需要多长时间，您是否有时间为您必须预热的任何缓存留出时间？
• 集合总共处理了多少请求？
• 我在图表中看到排队时间从图表左侧的初始峰值显着下降 - 知道为什么吗？这是启动时间吗？这是缓存变暖吗？在测试开始时是否有大量请求不成比例地出现？

你是唯一能回答这些问题的人。

如果我正确理解 Heroku 的设置，排队时间本质上是新请求等待可用独角兽的时间（或者更准确地说是独角兽，请求在被独角兽抓住之前等待多长时间）。如果您正在负载测试并为系统提供超出其处理能力的系统，而您的应用程序本身我的服务请求它已准备好快速处理，仍然会有积压的请求等待可用的独角兽处理它。

根据您的原始设置，在您的测试中尝试以下变量：

• 总请求数相同，但运行时间更长，以查看缓存是否预热更多并加快响应时间（即独角兽每秒处理更多请求）
• 将每秒的请求数调整为可用的独角兽的总集合，向上和向下，并观察排队时间在什么阈值处变得更好和更差
• 简化测试。首先，只需测试一个独角兽进程并弄清楚预热需要多长时间，每秒可以处理多少个请求，以及由于积压，排队时间在什么时候开始增加。然后，添加独角兽进程并重复测试，试图找出如果使用 3 个独角兽，您是否获得了 3 倍的性能，或者添加更多独角兽是否有一些 % 开销（例如，负载平衡传入请求的开销），以及是否开销是否可以忽略不计，等等。
• 确保请求都非常相似。如果您有一些请求只是返回具有 100% 缓存和非动态内容的首页，您的处理时间将比需要生成可变数量的动态内容的请求短得多，这会影响您的测试结果相当。

另外，找出您在上面显示的测试结果图表是平均值，还是带有标准偏差的95%或其他测量值。

只有在您将问题分解为其组成部分之后，您才能以任何可预测的方式知道添加更多独角兽是否会有所帮助。看着这个基本图表并问：“我应该添加更多独角兽吗？” 就像有一台速度很慢的计算机并问：“我应该为我的机器添加更多 RAM 吗？”。虽然它可能会帮助您跳过实际理解为什么会变慢的步骤，并且添加更多的东西虽然可能会有所帮助，但不会让您更深入地了解为什么会变慢。正因为如此（尤其是在heroku上），当你不需要它们时，你可能会为更多的dynos多付钱，只要你能找到导致排队时间比预期更长的根源，你会在很多更好的形状。

当然，这种方法并不是 heroku 独有的。尝试实验、调整变量并记录结果测量结果将使您能够分辨出这些性能数据中发生了什么。了解“为什么”将使您能够采取具体的、受过教育的步骤，这些步骤应该对整体性能产生大部分可预测的影响。

毕竟，您可能会发现，是的，在您的特定情况下提高性能的最佳方法是添加更多独角兽，但至少您会知道为什么以及何时这样做，以及一个非常可靠的猜测要添加多少。

Answer 2

我基本上写了另一个问题，然后坐下来，意识到我一周前刚刚编辑了这个确切的问题，并且知道两个问题的答案。

jefflunt 所说的基本 100% 正确，但是，因为我在这里，所以我在这里拼写出来。

有2个解决方案：

1. 添加更多独角兽工人。
2. 减少请求的总事务时间。

它们基本上归结为相同的确切概念，但是：

• 如果您每分钟有 15k 笔交易，那么您每秒将有 250 笔交易。
• 如果您的平均事务时间为 100 毫秒，则每个工作人员每秒可以执行 10 个事务（其中 1000 毫秒/（100 毫秒/事务））。
• 如果您有 8 台测功机和 3 名工人，那么您将有 24 名工人。
• 每秒 10 个事务的 24 个工作人员意味着您当前的设置每秒可以产生大约 240 个事务。

当然，这只是关于如何衡量问题的最粗略的框架，特别是因为流量总是以某种方式加权，并且取平均值（超过中位数）通常是更好的衡量标准，因为你更多地考虑了 95%请求，但您将接近正确的数字以了解您需要什么样的容量。