这个问题比较具体,我会尽量简明地说明:
我们在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的所有链接。