【问题标题】:page is being received too long页面接收时间过长
【发布时间】:2012-07-27 09:32:02
【问题描述】:

我已经将 Web 应用程序从使用 mod_python 改写为使用 mod_wsgi。问题是现在至少需要 15 秒才能处理任何请求(萤火虫暗示几乎所有这些时间都花在了接收数据上)。在重写之前,它花费了不到 1 秒的时间。我使用 werkzeug 进行应用程序开发,使用 apache 作为服务器。服务器负载似乎很小,内存使用也是如此。我正在使用 apache2-mpm-prefork。

我正在使用 mod_wsgi 的默认设置——我认为它被称为“嵌入式模式”。 我已经测试过切换到 apache2-mpm-worker 是否会有所帮助,但没有。 从应用程序日志来看,应用程序似乎很快就完成了请求 - 不到 1 秒。 我已将 apache 日志更改为调试,但我看不到任何可疑之处。 我已将应用程序移到另一台机器上运行,但一切都一样。

提前感谢您的帮助。

【问题讨论】:

    标签: apache mod-wsgi werkzeug


    【解决方案1】:

    听起来有点像您的响应内容长度与您实际发送回的数据量不匹配,返回的内容长度更长。因此浏览器会等待更多数据,直到可能超时。

    使用类似的东西:

    http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response

    验证正在发回的数据以及内容长度等内容是否匹配。

    否则,如果您没有展示说明问题的小型自包含代码示例,则无法猜测是什么问题。

    【讨论】:

    • 感谢您的回复。传输编码设置为分块。无论如何,我现在知道问题出在哪里——生成的 640 KB 页面是通过超过 400 000 个数据包发送的。几乎 100% 的数据包大小在 40 - 80 字节之间。知道为什么会这样吗?
    • 可能您正在从 WSGI 应用程序中生成一个字符串,而不是字符串的可迭代对象,例如字符串列表。如果您返回一个字符串,WSGI 服务器会将其视为长度为一个字符的字符串的可迭代,并一次刷新每个字符。如果没有设置内容长度并且下面的 Web 服务器将其作为分块传输编码发送,这将导致大量块。见code.google.com/p/modwsgi/wiki/…
    • 谢谢,就是这样!你太棒了!
    猜你喜欢
    • 2011-07-07
    • 2011-11-21
    • 1970-01-01
    • 1970-01-01
    • 2015-05-15
    • 1970-01-01
    • 1970-01-01
    • 2020-01-25
    • 1970-01-01
    相关资源
    最近更新 更多