28

我正在编写接受带有 json 数据的 POST 请求的烧瓶应用程序。我注意到基于传递给应用程序的数据大小的响应时间存在巨大差异。调试后，我将问题缩小到从请求对象中检索 json 数据的行。值得注意的是，测试是在烧瓶开发服务器上完成的。

start = time.time()
resp = json.dumps(request.json)
return str(time.time() - start)

我对这条线进行了计时，对于 1024 的数据（可能不是巧合）和更少的字符，这需要 0.002 秒，超过 1024 的任何数据都需要 1 秒！这里发生了什么？这是开发服务器的限制吗？

编辑：通过 request.form.get('somedata') 获取内容长度超过 1024 的 POST 数据也会发生同样的事情

编辑：我无法用 Apache 提供的相同示例复制问题

编辑： 我开始深入研究 Werkzeug 模块，发现在读取self._read(to_read)从 BaseHTTPRequestHandler 传递的 wsgi.py 模块中的响应消息时会出现缓慢。还是不知道为什么这么慢。

这是环境详细信息：Ubuntu - 10.04 Python - 2.6.5 Flask - 0.9 Werkzeug - 0.8.3

4

3 回答 3

6

烧瓶开发服务器预计会很慢。来自http://flask.pocoo.org/docs/deploying/：

您可以在开发期间使用内置服务器，但您应该为生产应用程序使用完整的部署选项。（不要在生产中使用内置的开发服务器。）

正如 Marcus 在评论中提到的，另一个像 gunicorn 或 tornado 这样的 WSGI 服务器会更快、更可靠，所以一定要使用其中一个进行部署和基准测试。

如果您担心在开发过程中快速工作，您可以像在部署中一样在开发中使用 gunicorn。例如，如果您要部署到 heroku，您可以运行“foreman start”，gunicorn 服务器将立即启动。

于 2012-12-15T06:08:20.190 回答
3

我在这样的线路上遇到了这个问题，大约需要 1.0 秒！它在烧瓶后处理程序中：

username=request.form.get('username')

我正在用 curl -F 测试它：

curl -F username="x" http://127.0.0.1:5000/func

我刚刚将 -F 更改为 -d ，它得到了 0.0004 秒！！！

curl -d username="x" http://127.0.0.1:5000/func

我认为烧瓶在检索“多部分/表单数据”内容类型时存在问题。

于 2013-07-17T01:39:51.163 回答
1

如果您使用 curl 发送请求，Expect: 100-continue可能会导致该行为。我在 uwsgi、flask 和 curl 中遇到了类似的行为。在我的情况下会发生以下情况：

  • 如果请求正文大小大于 1024 字节，curl 会发布带有 Expect: 100-continue 标头的数据。
  • 但是，uwsgi 无法处理标头。所以 uwsgi 没有响应 100-继续。
  • curl 等待 100-continue 响应，直到大约一秒超时。

当 curl 发送 100-continue | Georg's Log对我了解 curl 行为很有用。

于 2019-10-28T02:33:30.737 回答