我们看到 Heroku 的性能不一致，这与最近的独角兽/智能路由问题无关。
这是一个请求的示例，通常需要大约 150 毫秒（20 次中有 19 次是需要多长时间）。您可以看到，在这个请求中，它花费了大约 4 秒，或者长了 1 到 2 个数量级。
需要注意的一些事项：
所以我想知道是什么导致这些偶尔的缓慢请求。正如我所提到的，有趣的是，它似乎发生在大约 20 个请求中的 1 个。我唯一能想到的就是盒子上有嘈杂的邻居问题，或者路由层的性能不一致。如果有人有其他信息或想法，我会很好奇。谢谢你。
我自己一直在追求类似的问题，到目前为止运气不佳。
我想首要任务是推荐 NewRelic。它可能会为您提供有关这些案例的更多信息。
其次，我建议您查看排队时间：您的请求排队了多长时间。查看 NewRelic，或者使用 Heroku 添加到传入请求中的“开始时间”HTTP 标头自己做（只需打印 now() 减去“开始时间”作为队列时间）。
当我的情况让我失败时，我尝试提出可能出错的事情，这里有一个（非正统的？奇怪的？）列表：
1) DNS——您是否在您的视野中进行任何 DNS 调用？这些可能需要一段时间。甚至用于解析 DB 主机名、Redis 主机名、外部服务提供商等的 DNS 请求。
2) 日志性能——Heroku 使用他们的“Logplex”收集你所有的标准输出，然后将其排入你自己定义的日志排水、Papertrail 等服务。没有关于此性能的文档，并从你的标准输出写入理论上，当 Heroku 刷新它可能在那里的任何缓冲区时，进程可能会阻塞一段时间。
3) 获取数据库连接——不确定您使用的是哪个框架，但也许您有一个连接池，您从中获取数据库连接，这需要时间？它不会显示为查询时间，它将成为您进程的阻塞时间。
4) Dyno 性能——Heroku 有一个附加功能，可以每隔几秒打印一些服务器指标（负载平均值、内存）到标准输出。我使用 Graphite 来绘制这些图表，并寻找指标与我看到“零星慢速请求”实例增加的时间之间的相关性。它没有帮助我，但可能会帮助你:)
请让我们知道您的想法。