相关疑难解决方法(0)

这是非常具体的,但我会尽量简短:

我们正在Heroku上运行Django应用程序.三台服务器:

1. 测试(1网,1芹菜dyno)
2. 培训(1网,1芹菜dyno)
3. prod(2网,1芹菜dyno).

我们使用Gunicorn与gevents和每个赛道4名工人.

我们正经历零星的高服务时间.以下是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秒超时的应用程序错误屏幕
• 高响应时间从5000毫秒到30000毫秒不等.
• New Relic并未指出具体问题.以下是过去的几笔交易和时间:
  • RegexURLResolver.resolve 4,270ms
  • SessionMiddleware.process_request 2,750ms
  • 渲染login.html 1,230ms
  • WSGIHandler 1,390ms
  • 以上是简单的通话,通常不会接近这段时间

我把它缩小到了:

1. 这篇关于Gunicorn和慢客户的文章
   • 我已经看到这个问题发生在缓慢的客户端,但也发生在我们有光纤连接的办公室.
2. Gevent和异步工作者玩得不好
   • 我们已经切换到gunicorn同步工作者,问题仍然存在.
3. Gunicorn工人超时
   • 工人可能会以某种方式保持活动状态.
4. 工人/动力不足
   • 没有指示CPU /内存/ db过度使用和New Relic没有显示DB延迟的任何指示
5. 吵闹的邻居
   • 在我与Heroku的多封电子邮件中,支持代表提到我的至少一个长期请求是由于一个吵闹的邻居,但不相信这是问题.
6. 子域301
   • 请求很顺利,但在应用程序中随机被卡住.
7. Dynos重启
   • 如果是这种情况,许多用户将受到影响.另外,我可以看到我们的dynos最近没有重启.
8. Heroku路由/服务问题
   • Heroku服务可能比宣传的要少,这只是使用他们服务的缺点.

过去几个月我们一直有这个问题,但现在我们正在扩展它需要修复.任何想法都会受到高度赞赏, …