Django 1.4.18 dev服务器在VirtualBox下响应缓慢 [英] Django 1.4.18 dev server slow to respond under VirtualBox

问题描述

我们正在使用Windows 7主机中的Ubuntu LTS 12.04虚拟机中的开发环境。我们在开发过程中使用./manage.py runserver。最近我们将Django版本升级到最新版本（1.4.19），但注意到一个非常奇怪的行为：来自主机的请求从5-30秒内提供服务，而虚拟机内部的请求应该在不到一秒的时间内提供。 Django 1.4.18中引入了这个问题（ https：//docs.djangoproject .com / fr / 1.7 / releases / 1.4.18 / ），所有较旧的版本都可以快速运行。

在访客或主机中使用不同的浏览器没有任何区别。请求的资源是动态的还是静态的（我们使用静态应用程序在开发过程中提供静态内容）也没有任何区别。

什么可能导致这种行为？从发行说明中我们并不清楚。

解决方案

哇我不敢相信我终于设法解决了这个问题。我刚刚发现同样的问题，你把我放在正确的轨道上，提到它只出现在Django 1.4.17之后版本。

简单解决方案：将您的网关IP添加到客户机中的/ etc / hosts，例如：

  10.0.2.2 10.0.2.2 
  

长说明： Django 1.4.18介绍了包含下划线的标题的剥离。这是无害的，但 django.core.servers.basehttp.WSGIRequestHandler.get_environ 方法略有更改。从1.4.18开始，它依赖于 wsgiref.simple_server.WSGIRequestHandler.get_environ ，其中包含以下行：

  host = self.address_string（）
  

address_string 是一个来自 BaseHTTPServer 的方法：

 <$ c $ 
 
此版本使用gethostbyaddr（），
查找完整的主机名，并尝试使用
 

 
 host，port = self.client_address [：2] 
 return socket.getfqdn（host ）
  

对getfqdn的调用是（缓慢）的罪魁祸首：

 在[1]中：import socket 
在[2]中：％时间socket.getfqdn（10.0.2.2）
 CPU次数：用户0 ns，sys：0 ns，总计：0 ns 
挂墙时间：1.56 s 
输出[2]：'10 .0.2.2'
  

在我添加了10.0.2.2 10.0.2.2之后在我的客机中，主机名解析已经接近即时：

 在[3]中：％时间socket.getfqdn（10.0.2.2）
 CPU时间：用户0 ns，sys：0 ns，总计：0 ns 
停留时间：834μs 
 Out [3]：'10 .0.2.2'
  

请注意，您的网关地址可以通过在客人环境中运行 route -n 找到。

We're running our development environment in a virtualbox Ubuntu LTS 12.04 guest, in Windows 7 host. We use ./manage.py runserver during development.

Recently we upgraded our Django version to latest (1.4.19) but noticed a very odd behaviour: requests coming from host machine take anything from 5-30s to serve, while requests from inside VM are served in less than a second, as they should be. The problem has been introduced in Django 1.4.18 (https://docs.djangoproject.com/fr/1.7/releases/1.4.18/), all older releases work fast.

Using different browser in guest or host makes no difference. It also does not make any difference whether the requested resource is dynamic or static (we use the static app to serve static content during development).

What could cause this kind of behaviour? From the release notes it's not immediately clear to us.

解决方案

Wow I can't believe I finally managed to solve this. I had exactly the same issue and you put me on the right track by mentioning that it only appeared for version later than Django 1.4.17.

Short solution: add your gateway IPs to /etc/hosts in your guest machine, e.g:

10.0.2.2 10.0.2.2

Long explanation: Django 1.4.18 introduced the stripping of headers that contain underscores. That's harmless, but the django.core.servers.basehttp.WSGIRequestHandler.get_environ method was slightly altered. From 1.4.18 on, it relies on wsgiref.simple_server.WSGIRequestHandler.get_environ, which contains the line:

host = self.address_string()

address_string is a method from BaseHTTPServer:

 def address_string(self):
    """Return the client address formatted for logging.

    This version looks up the full hostname using gethostbyaddr(),
    and tries to find a name that contains at least one dot.

    """

    host, port = self.client_address[:2]
    return socket.getfqdn(host)

That call to getfqdn is the (slow) culprit:

In [1]: import socket
In [2]: %time socket.getfqdn("10.0.2.2")
CPU times: user 0 ns, sys: 0 ns, total: 0 ns
Wall time: 1.56 s
Out[2]: '10.0.2.2'

After I added the "10.0.2.2 10.0.2.2" line to /etc/hosts in my guest machine, hostname resolution was near instant:

In [3]: %time socket.getfqdn("10.0.2.2")
CPU times: user 0 ns, sys: 0 ns, total: 0 ns
Wall time: 834 µs
Out[3]: '10.0.2.2'

Note that your gateway address can be found by running route -n in your guest environment.

这篇关于Django 1.4.18 dev服务器在VirtualBox下响应缓慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！