我见过两种使用gunicorn和nginx托管django应用程序的策略。
一种策略是在网络端口上运行gunicorn。例如（从goodcode）：
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/;
}另一个策略是在启动时将gunicorn绑定到UNIX套接字（例如from here）
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;
}
}关于哪种策略上级的想法？对于每种策略的正确方法有什么评论吗？我倾向于套接字方法，因为我认为TCP会引入开销。我最关心的是我所看到的实现示例之间在头文件、连接超时等方面的差异。
5条答案
按热度按时间wn9m85ua1#
除了TCP/IP开销小，没有太大的区别。每个listen（）套接字获得一个连接队列，而accept（）只是从该队列弹出一个连接。在gunicorn中，每个worker只是根据自己的能力从该队列弹出一个新连接，这样就不会改变。区别在于性能（套接字更快一点）和可移植性（端口：IP更灵活）。Unix域套接字将给予你更好的性能，而连接到localhost的套接字给你更好的可移植性。如果你将服务器应用移动到不同的操作系统，你可以通过将IP地址从localhost改为不同的主机名来实现。
kninwzqo2#
下面是我通过Unix套接字测试TCP代理的结果：
安装：nginx + gunicorn + django运行在AWS上的4个m4.xlarge节点上。每个节点的安装是统一的（来自同一个映像）。
在大约30分钟的窗口内发出了100万个请求：
其中一个示例的CPU占用率为100%，因为其中一个服务器上运行着不相关的作业。另外3个示例的CPU占用率为70%，每个示例都代表真实的的应用程序负载。
TCP与套接字几乎完全相同
提出1000000项要求的时间
TCP代理为27分钟
而UNIX套接字为31分钟。
在这个特殊的设置中，unix socket没有性能优势。
eqzww0vc3#
如果你的网络服务器和应用程序服务器（wsgi）在同一台机器上，套接字流量将是一个简单的选择。但是，你将需要网络连接上的网络端口，因为套接字不能在网络上工作，所以..
1.如果Web服务器和应用程序服务器位于同一台计算机上-使用套接字
1.如果网络服务器和应用程序服务器在网络上- GO PORTS
oxcyiej74#
我更喜欢套接字通信超过TCP/IP因为没有额外的端口是需要被打开.越少的端口打开越坚固你的系统变得
如这里所建议的“偏执”https://hynek.me/talks/python-deployments/
1aaf6o9v5#
我知道我来晚了，如果你想让它在带有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