这个问题比较具体，我会尽量简明地说明:
我们在Heroku上运行一个Django应用程序，有三个服务器：
- 测试（1个Web，1个Celery Dyno）
- 培训（1个Web，1个Celery Dyno）
- 生产（2个Web，1个Celery Dyno）
我们使用Gunicorn和gevents，在每个Dyno上有4个worker。
我们经历了零散的高服务时间。以下是来自Logentries的示例:
High Response Time:
heroku router - - at=info
method=GET
path="/accounts/login/"
dyno=web.1
connect=1ms
service=6880ms
status=200
bytes=3562
我已经搜索了几周了，但我们无法复现这个问题，每天会遇到0-5次警报。注意点：
- 所有三个应用程序上都发生（所有运行相似代码）
- 发生在不同的页面上，包括像404和/admin这样的简单页面
- 在随机时间发生
- 吞吐量不同。我们的一个实例只有3个用户/天。它与睡眠dynos无关，因为我们使用New Relic进行ping测试，问题可能会在会话中发生
- 无法随意复现。我个人经历过这个问题一次。单击通常需要500毫秒执行的页面会导致30秒的延迟，最终出现Heroku的30秒超时错误屏幕
- 高响应时间范围为5000ms - 30000ms。
- New Relic没有指向特定问题。以下是过去的几个交易和时间：
- RegexURLResolver.resolve
4,270ms - SessionMiddleware.process_request
2,750ms - Render login.html
1,230ms - WSGIHandler
1,390ms - 以上是简单的调用，通常不需要那么长时间
- RegexURLResolver.resolve
我已经排除的问题:
这篇关于Gunicorn和慢客户端的文章- 我看到此问题发生在慢客户端以及我们的办公室，我们有光纤连接。
Gevent和异步工作程序不友好- 我们已切换到gunicorn同步工作程序，但问题仍然存在。
- Gunicorn工作程序超时
- 工作程序可能以空状态保持活动状态。
工人/ dynos不足- 没有CPU /内存/ db过度利用的迹象，New Relic也没有显示任何关于DB延迟的迹象
- 嘈杂的邻居
- 在与Heroku的多封电子邮件中，支持代表提到了我的一个长请求是由于嘈杂的邻居引起的，但并不确定是否是问题的原因。
子域301- 请求正常通过，但随机卡在应用程序中。
Dynos重新启动- 如果是这种情况，将影响许多用户。此外，我可以看到我们的dynos最近没有重新启动。
- Heroku路由/服务问题
- 可能是Heroku服务不如宣传的那样好，这只是使用他们服务的一个缺点。
我们已经遇到了这个问题几个月了，但现在我们正在扩展它需要解决。 非常感谢任何想法，因为我几乎用尽了SO或Google的所有链接。
