Heroku 排队时间

Question

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

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

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

任何建议表示赞赏。

Answer 1

基本上，将问题分解为各个部分并测试每个部分。简单地向独角兽集群抛出一堆请求不一定是衡量吞吐量的好方法。您必须考虑许多变量（旁注：checkout "Programmers Need To Learn Statistics Or I Will Kill Them All" by Zed Shaw）

此外，您在问题中遗漏了用于解开谜团的关键信息。

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

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

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

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

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

另外，看看您上面显示的测试结果图表是an average，还是95th percentile 和standard deviations，或者其他一些度量。

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

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

在所有这些之后，您可能会发现是的，在您的特定情况下提高性能的最佳方法是添加更多独角兽，但至少 您会知道原因和时间 这样做，以及对要添加 多少 的非常可靠的猜测。

Answer 2

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

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

有两种解决方案：

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

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

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

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