【问题标题】:Flask on Heroku: request.form is incredibly slow with large POST data?Heroku 上的 Flask:对于大量 POST 数据,request.form 速度非常慢?
【发布时间】:2013-01-27 05:29:19
【问题描述】:

我正在 Heroku 上运行一个 Flask 应用程序,使用 gunicorn 和 eventlet 工作者。我的应用程序上的一个特定路由经常接收带有一些相当大的字段的 POST 数据(x-www-form-urlencoded)——最多大约 500KB。

这在本地运行时运行良好,但在 Heroku 上,对该路由的请求需要 5 到 30 秒才能完成——并且几乎 100% 的时间都花在了第一次访问 request.form 上:

t = time.time()
action = str(request.form['action'])
dt = time.time() - t  # Often 10 seconds or more!

Newrelic 慢速请求跟踪也证实了这一点。数据库操作在这里或那里有几毫秒,然后是 Python 代码中的大量时间,显然花在等待一些 i/o 上,因为报告的 CPU 时间通常不到一毫秒。

我完全无法在本地环境中使用我在生产中使用的相同 gunicorn/eventlet 设置重现此问题。即使是内置的调试 WSGI 服务器也能以闪电般的速度处理这些请求。

有人知道可能出了什么问题吗?是 Flask 的问题,还是我需要联系 Heroku 支持?

【问题讨论】:

  • 您是否尝试过将应用程序放在 dotcloud 的免费沙盒上?我最近将它用于一个小型 Flask 应用程序,它非常简单。也许在那里或类似的地方测试你的应用程序,看看你是否可以用 Heroku、Flask 或你的应用程序找出问题?
  • 我第二个 @AllanAnderson - 在另一个供应商上尝试类似的设置 - 如果它以相同的方式中断,您能否提供一些导致问题的示例数据?
  • “并且几乎 100% 的时间都花在了第一次访问 request.form 上” 您是否可能正在经历测功机空转的影响? devcenter.heroku.com/articles/dynos#dyno-idling
  • @AllanAnderson, Sean:这些都是很好的建议;我想我会尝试并报告。
  • @Dominic:绝对不​​是空转。该应用程序有多个专门运行的网络测功机以避免空转;我还添加了跟踪代码,以便它测量请求函数开始执行后开始的时间。

标签: python post heroku flask gunicorn


【解决方案1】:

我想我知道到底发生了什么。 TL;DR 实际上服务器端一点也不慢,我只是被 Newrelic 报告的响应时间误导了!

我尝试在 dotCloud 的沙盒上运行与 @AllanAnderson 建议的相同的代码。我首先创建了一个简化的测试用例:一个简单的 HTML 表单,其中预先加载了大约 900KB 数据的几个隐藏字段,以及一个除了从 request.form 字典中读取之外什么都不做的视图函数,并使用测量每次访问的经过时间time.time().

在 Heroku 上,结果如下所示:

5.87100 seconds: read field "p1": 786432 bytes
0.00019 seconds: read field "p2": 131072 bytes
0.00003 seconds: read field "p3": 12288 bytes
0.00001 seconds: read field "p4": 1024 bytes

在 dotCloud 上:

0.00096 seconds: read field "p1": 786432 bytes
0.00019 seconds: read field "p2": 131072 bytes
0.00003 seconds: read field "p3": 12288 bytes
0.00001 seconds: read field "p4": 1024 bytes

但是,在我的浏览器中,这两个测试似乎都花费了相同的时间……现在您可能已经猜到了这个“问题”的真正答案。 :-)

事实证明 Heroku 上的 gunicorn 在收到标头后立即执行视图功能,并且对 request.form 的第一次访问被阻塞,直到收到请求的其余部分。所以 Newrelic 看到了所有这些非常慢的响应时间,这些响应时间实际上只是通过糟糕的网络连接上传 POST 数据的结果。 dotCloud 的设置显然只是等到收到整个请求。

这会降低 Newrelic 的指标的用处,但这实际上并不是最终用户体验的问题。

【讨论】:

  • 很高兴听到您整理出误导您的指标的内容。耶消除过程!
猜你喜欢
  • 2015-12-03
  • 1970-01-01
  • 2019-04-10
  • 2013-03-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-08-28
  • 1970-01-01
相关资源
最近更新 更多