networking - 找到flask应用的瓶颈

Question

我写了一个 flask 应用程序。当我将它部署到远程服务器时，我发现它非常慢。
所以，我用它做了一些分析实践。
请看下面的图片:

我用来分析的代码是:

#coding: utf-8
from werkzeug.contrib.profiler import ProfilerMiddleware
from app import app

app.config['PROFILE'] = True
app.wsgi_app = ProfilerMiddleware(app.wsgi_app, restrictions = [30])
app.run(debug = True)

图片1

中的分析远程服务器 .
也许瓶颈是 _socket.getaddrinfo


图2

在本地机器上进行分析。
没有发现瓶颈。



图3

有时，即使在远程服务器中，也没有发现瓶颈。否 _socket.getaddrinfo成立。奇怪的!


我也在远程服务器 python shell 中进行了分析，使用 cProfile .
看看这个:

In [10]: cProfile.run("socket.getaddrinfo('easylib.gdufslib.org', 80, 0, 0, socket.SOL_TCP)")
3 function calls in 8.014 CPU seconds

Ordered by: standard name

ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 8.014 8.014 :1()
1 8.014 8.014 8.014 8.014 {_socket.getaddrinfo}
1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects}



In [11]: cProfile.run("socket.getaddrinfo('easylib.gdufslib.org', 80, 0, 0, socket.SOL_TCP)")
3 function calls in 8.009 CPU seconds

Ordered by: standard name

ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 8.009 8.009 :1()
1 8.009 8.009 8.009 8.009 {_socket.getaddrinfo}
1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects}


也许有一个事实，做一些事情需要很多时间 dns resolve工作，而我自己无法改变这一点。

谁能告诉我:为什么 _socket.getaddrinfo被称为，为什么有时不被称为？
如何预防 _socket.getaddrinfo被叫？因为它拖慢了我的网站，这让我很伤心。

Answer 1

我刚刚在一个运行在 Digital Ocean 专用盒子上的 Flask 应用程序上遇到了这个问题，所以我会发布解决方案，以防其他人将来遇到这个问题。

几天前我注意到对 GitHub 的 API 请求非常慢，有时需要 10 到 20 秒。但是在本地运行我的应用程序没有任何问题。我分析了我的应用程序，和 socket.getaddrinfo确实是罪魁祸首:

1 15058.431 15058.4310 15058.431 15058.4310 {_socket.getaddrinfo}
1 26.545 26.5450 26.545 26.5450 {_ssl.sslwrap}
1 23.246 23.2460 23.246 23.2460 {built-in method do_handshake}
4 22.387 5.5968 22.387 5.5968 {built-in method read}
1 7.632 7.6320 7.632 7.6320 {method 'connect' of '_socket.socket' objects}
103 4.995 0.0485 7.131 0.0692 <s/werkzeug/urls.py:374(url_quote)>
2 2.459 1.2295 2.578 1.2890 <ssl.py:294(close)>
36 1.495 0.0415 10.548 0.2930 <s/werkzeug/routing.py:707(build)>
859 1.442 0.0017 1.693 0.0020 {isinstance}
.... etc.

与 Digital Ocean 支持合作，并怀疑它在某种程度上是 DNS 问题，工作解决方案是更改(在 /etc/resolv.conf 中)

nameserver 4.2.2.2
nameserver 8.8.8.8

到

nameserver 8.8.4.4
nameserver 8.8.8.8

无论出于何种原因， 4.2.2.2 (由 Level3 运营)决定它讨厌我，但暂时我和 Google 的 DNS 很酷。

更新:我的同事 Karl 建议我继续使用 bind 设置一个本地 DNS 缓存服务器，以防止 Google 的 DNS 也讨厌我。 This link was super helpful.