mas*_*rre 30 django nginx gunicorn
我已经看到了使用gunicorn和nginx托管django应用程序的两种策略.
一种策略是在网络端口上运行gunicorn.例如(来自http://goodcode.io/blog/django-nginx-gunicorn/):
location / {
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_connect_timeout 10;
proxy_read_timeout 10;
proxy_pass http://localhost:8000/;
}
Run Code Online (Sandbox Code Playgroud)
另一个策略是在启动时将gunicorn绑定到UNIX套接字(例如http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/)
upstream hello_app_server {
server unix:/tmp/gunicorn.sock fail_timeout=0;
}
...
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
if (!-f $request_filename) {
proxy_pass http://hello_app_server;
break;
}
}
Run Code Online (Sandbox Code Playgroud)
关于哪种策略优越的想法?有关正确方法的任何评论吗?我倾向于套接字方法,因为我想象的开销是由TCP引入的.我最关心的是标头,连接超时等之间的差异以及我见过的实现示例之间的差异.
rad*_*tek 26
除了小的TCP/IP开销之外,没有太大区别.每个listen()套接字都获得一个连接队列,而accept()只是弹出该队列的连接.在gunicorn中,每个工作人员只是从该队列弹出一个新连接,因为它不会改变.不同之处在于性能(套接字更快)和可移植性(端口:IP更灵活).Unix域套接字可以提供更好的性能,而连接到localhost的套接字可以让您在将服务器应用程序移动到其他操作系统时具有更好的可移植性,只需将IP地址从localhost更改为其他主机名即可.
Kas*_*qui 15
如果您的网络服务器和应用服务器(wsgi)都存在于同一台机器上,则套接字流量将是一个简单的选择.但是,您将需要通过网络连接的网络端口,因为套接字不能通过网络工作,所以..
更喜欢 TCP/IP 上的套接字流量,因为不需要打开额外的端口。打开的端口越少,您的系统就越坚固
正如这里所建议的“偏执” https://hynek.me/talks/python-deployments/
“具有限制性权限的 UNIX 文件套接字是您的朋友。您可以停止提出端口号”
我知道我参加这个聚会迟到了,如果您想在强制执行 SELinux 的 Red Hat 风格 Linux 上使用它,那么这可能会有用。
如果您尝试使用套接字,它会严重妨碍您。我放弃。
如果您尝试通过任意 TCP 端口绑定 Gunicorn,它也会造成妨碍。默认情况下(在 Centos 1708 上)SELinux 很乐意使用一个端口子集:80,81,443,488,8008,8009,8443,9000
我选择了 8009 但显然你可以使用其他一些端口
semanage -a -t http_port_t -p tcp $PORTNUMBER
并查看端口列表
semanage port -l
这是通过Unix套接字测试TCP代理的结果:
设置:在AWS的4 m4.xlarge节点上运行的nginx + gunicorn + django。
在大约30分钟的时间内发出了1百万个请求:
1个实例的CPU利用率为100%,另外3个实例的CPU利用率均为70%。
TCP与套接字实际上是相同的 ,发出1000000个请求的时间
TCP代理是27分钟
Unix套接字需要31分钟。
在此特定设置中,没有Unix套接字性能优势。
| 归档时间: |
|
| 查看次数: |
15025 次 |
| 最近记录: |