Python 请求模块在特定机器上非常慢

Question

我曾遇到过在某些机器上和特定用户执行 Python 请求时速度太慢而其他工具(例如 curl)却相当快的情况。奇怪的是，如果以另一个用户身份运行脚本，那么它会按预期运行。如果我在我的机器(Windows 或 Linux)上运行脚本，那么它也会按预期运行。有问题的机器是 Hyper-V 上的 Windows 2008 服务器。我通常使用 POST 请求，但 POST 和 GET 都会受到影响。为了演示，我创建了带有 GET 请求的简单脚本。所有请求大约需要 4.8 秒，但应该需要大约 0.03 秒(虚拟机没有那么强大)。

[imports and logging configuration omitted]

log.info("Started ...")

start = time.time()
response1 = requests.get("http://10.50.30.216:8080/sps/api/version")
assert response1.status_code == codes.OK
log.info("Using requests: %.3fs" % (time.time() - start))

start = time.time()
conn = httplib.HTTPConnection("10.50.30.216:8080")
conn.request("GET", "/sps/api/version")
response2 = conn.getresponse()
assert response2.status == codes.OK
log.info("Using httplib: %.3fs" % (time.time() - start))

log.info("Finished ...")

作为有问题的用户登录时的输出(不幸的是我必须使用该用户)。看到请求模块在打开连接之前等待 4.523 秒，而 httplib 模块立即继续。

2015-09-11 14:50:00,832 - INFO - myscript - Started ...
2015-09-11 14:50:05,355 - INFO - requests.packages.urllib3.connectionpool - Starting new HTTP connection (1): 10.50.30.216
2015-09-11 14:50:05,364 - DEBUG - requests.packages.urllib3.connectionpool - "GET /sps/api/version HTTP/1.1" 200 None
2015-09-11 14:50:05,365 - INFO - myscript - Using requests: 4.533s
2015-09-11 14:50:05,374 - INFO - myscript - Using httplib: 0.008s
2015-09-11 14:50:05,375 - INFO - myscript - Finished ...

以其他用户身份登录时的输出。请注意，这两个用户都有管理员权限，但第二个用户只是临时用户，并且只在一台机器上，所以我无法通过切换用户来解决这个问题。

2015-09-11 14:57:45,789 - INFO - myscript - Started ...
2015-09-11 14:57:45,799 - INFO - requests.packages.urllib3.connectionpool - Starting new HTTP connection (1): 10.50.30.216
2015-09-11 14:57:45,806 - DEBUG - requests.packages.urllib3.connectionpool - "GET /sps/api/version HTTP/1.1" 200 None
2015-09-11 14:57:45,809 - INFO - myscript - Using requests: 0.021s
2015-09-11 14:57:45,815 - INFO - myscript - Using httplib: 0.004s
2015-09-11 14:57:45,815 - INFO - myscript - Finished ...

我读过 Python requests are slow #1和 Python requests are slower thann curl但它不适用于我的问题。

Answer 1

对于阅读本文并在其 URL 中使用 localhost 的任何人，我通过将其更改为 127.0.0.1 解决了这个问题。

如果这样可以解决问题，则说明是 DNS 问题，而不是请求问题。