进入Django's的速度慢请求.正文

Question

有时候，这一行Django应用程序（使用Apache/mod wsgi托管）在由一些移动客户端提交时需要花费大量时间来执行（例如，99%的请求处理时间，如newrelic所测量的6秒）：

raw_body = request.body

（其中request是一个传入请求）

我的问题是：

1. 是什么让访问request.body的速度慢了这么多？在
2. Apache在调用Django之前等待的正确配置是什么，直到客户机发送整个负载？可能问题出在Apache配置中。在

Django的^{} attribute in ^{} is a property，因此它真正解决了在Django应用程序之外到底在做什么，以及如何在Django应用程序之外实现它。我希望Apache在发送到Django应用程序之前等待完整的请求。在

Answer 1

恐怕问题出在你传输的数据量上，可能是连接速度慢。还要注意，上传带宽通常比下载带宽小得多。在

如前所述，当您使用request.body时，Django将等待整个主体从客户端完全传输到服务器上的内存（或磁盘上，根据配置和大小）可用。在

我建议您尝试一下，如果客户端连接到一个WiFi接入点（WiFi接入点与服务器本身相连）时，同样的请求会发生什么情况，看看它是否得到了改善。如果这是不可能的，也许只要运行一个工具速度测试.net在客户机上，获取请求大小并进行计算，以确定理论上需要多少时间（我预计测量时间大约多20%）。请注意，网络速度通常以位/秒为单位，而文件大小以字节为单位。在

在某些情况下，如果需要对数据进行大量处理，则可以方便地read()请求并进行计算，或者直接将request对象传递给任何可以从所谓的“类似文件的对象”而不是字符串读取的函数。在

但是，在你的具体情况下，恐怕这只会影响到1%的时间，而不是花在接收来自网络的尸体上。在

编辑：

抱歉，只是现在我注意到悬赏单上有额外的描述。恐怕我帮不了你，但是，我可以问一下，有什么意义吗？我想这只会节省一点点服务器资源，使python线程暂时处于空闲状态，而对请求没有任何明显的性能提升。。。在

Answer 2

关于（1），只要请求的头可用，Apache就将控制权传递给mod_wsgi处理程序，然后mod_wsgi将控制权传递给Python。然后，request.body的内部实现调用read()方法，该方法最终调用mod uwsgi中的实现，requests the request's body from Apache如果Apache还没有完全接收到它，则会阻塞直到它可用为止。在

关于（2），这是不可能单独使用mod\wsgi。至少，the hook processing incoming requests在完整请求可用之前不提供阻止机制。另一张海报建议在a response to this duplicate question中使用nginx作为代理。在

Answer 3

在Apache中有两种方法可以解决这个问题。在

您可以使用>=2.3中提供的mod_buffer，并将{}更改为预期的最大负载大小。这将使Apache将请求保存在内存中，直到它完成发送或到达缓冲区。在

对于较旧的Apache版本< 2.3，可以将mod_proxy与ProxyIOBufferSize、ProxyReceiveBufferSize和环回vhost结合使用。这涉及到将您的真实vhost放在环回接口上，并公开一个连接回真实vhost的代理vhost。这样做的缺点是它使用了两倍多的套接字，并且可能使resource calculation变得困难。在

然而，最理想的选择是在L4/L7负载平衡器上启用请求/响应缓冲。例如，haproxy允许您基于req_len添加rules，对{a6}也是如此。大多数好的商业负载平衡器也有一个选项，在发送请求之前缓冲请求。在

这三种方法都依赖于缓冲完整的请求/响应有效负载，并且根据您的用例和可用的资源，还有一些性能方面的考虑因素。您可以将整个负载缓存在内存中，但这可能会显著降低最大并发连接数。您可以选择将有效负载写入本地存储（最好是SSD），但随后会受到IO容量的限制。在

您还需要考虑文件上传，因为这些文件不适合基于内存的有效负载缓冲。在大多数情况下，您将在Web服务器中处理上载请求，例如HttpUploadModule，然后查询nginx中的upload progress，而不是直接在WSGI中处理它。如果您在负载平衡器上进行缓冲，那么您可能希望从缓冲规则中排除文件上载。在

您需要了解why this is happening，并且在发送响应和接收请求时都存在此问题。有这些保护也是一个好主意，不仅仅是为了可伸缩性，而且是为了security reasons。在