我正在尝试将nginx安装扩展到最好的能力。
我正在运行一个具有6个worker_processes（6个核心）和5个后端服务器的nginx实例，每个服务器由10个工人组成的uwsgi设置组成。 （共有50名工人）。
不过，我尝试使用不同参数（使用ab ）进行全连接和并发连接的任何基准testing似乎都以约1000个请求/秒的速度出现。
我已经禁用所有的日志loggingnginx和uwsgi（为了避免由于磁盘问题而变慢）。 我正在testing一个仅仅发送{'status':'ok'}的Flask python应用程序。 没有数据库访问，没有计算，没有。
nginxconfiguration的相关部分如下所示：
user www-data; worker_processes 6; worker_rlimit_nofile 100000; pid /var/run/nginx.pid; events { use epoll; worker_connections 2048; multi_accept on; } http { ## # Basic Settings ## sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # server_tokens off; # server_names_hash_bucket_size 64; # server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; ## # Logging Settings ## access_log off; # /var/log/nginx/access.log; error_log /var/log/nginx/error.log; <...> }
我正在寻找任何提示，任何我忽略了，以提高吞吐量。 查看每个uwsgitop池的统计信息（使用uwsgitop ），他们在任何时候似乎都很难执行，导致我相信nginx是瓶颈。 此外，性能也是一样的，而不是10人。此外， htop还表明我在内存或CPU方面htop没有达到最大值。
我build议你安装sysstat包，然后用sar检查录制的信息。
sar -n SOCK -s <start_time> -e <end_time>在基准testing期间获取套接字的数量
sar -n DEV -s <start_time> -e <end_time>来获取networking接口数据包和带宽
sar -d -s <start_time> -e <end_time>来获得每个设备的io统计信息
sar -v -s <start_time> -e <end_time>来获取文件句柄和inode的数量
等等
检查用户的安全限制（最大打开文件数，最大进程数等）。
然后检查你的内核设置：本地端口范围，somaxconn，设备txqueue，netdev backlog，在nginx或tcp_tw_recycle中使用SO_LINGER激活需要TIME_WAIT状态的套接字（关于带有sar -n SOCK的tcp-tw）如果需要的话，改变tw_buckets的数量，确保启用了sack / dsack和时间戳，减lessFIN_WAIT_2超时，增加最大文件句柄等等。
可能有很多因素。
在检查所有这些之前，请确保您不要在同一台设备上运行ab ，并且python应用程序具有良好的响应时间。
而一个简单的testing，以确保python应用程序不是罪魁祸首：由nginx直接服务器上的静态文件相同的基准。
除了这里的其他两个答案，conntrack（连接跟踪）也可能是一个问题。 如果您正在使用Linux，并且您正在使用netfilter（即iptables），则conntrack表可能已满。
首先检查是否启用了conntrack。 例如：
$ /sbin/lsmod | grep conntrack ip_conntrack 51617 1 xt_state $ lsmod | grep -i con nf_conntrack_ipv4 19159 5 nf_defrag_ipv4 12729 1 nf_conntrack_ipv4 nf_conntrack 92358 5 xt_state,iptable_nat,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat
输出将根据内核版本而有所不同。
如果加载了nf_conntrack或者ip_conntrack模块，你可以看到有多lessconntrack条目，并且检查你的max是什么：
红帽（RHEL，CentOS，Fedora等）：
$ sudo wc -l /proc/net/ip_conntrack $ /sbin/sysctl -a | grep conntrack_max or $ sudo wc -l /proc/net/nf_conntrack $ /sbin/sysctl -a | grep conntrack_max
Debian的：
$ cat /proc/sys/net/netfilter/nf_conntrack_count $ /sbin/sysctl -a | grep conntrack_max
如果你填满了conntrack表，那么你将需要通过sysctl或/etc/sysctl.conf来增加限制。
注意 ：conntrack不只适用于服务器。 您需要检查自己和服务器之间的每个点：客户端计算机，负载平衡器（nginx），上游（后端）服务器，甚至可能是任何路由器。
我会看看文件描述符，可能的networking/接口饱和度和IO问题。
要查看networking接口是否饱和，请使用iptraf这是一个命令行工具来查看实时统计信息。 只是：
iptraf
对于IO问题，使用iostat
iostat 1
这将显示IO使用情况和负载每1秒。
对于文件描述符问题，使用lsof或/ proc：
lsof -P -n -p <PID> | wc -l ls /proc/<PID>/fd | wc -l
使用ulimit -a | grep files ulimit -a | grep files命令（作为运行该进程的用户）来validation允许打开多less个文件。 默认值是1024。
有关详细信息，请参阅此页： http : //www.cyberciti.biz/tips/linux-procfs-file-descriptors.html
看到这个问题的nginx特定的文件描述符问题，这可能很有可能与您的问题有关： 了解Linux和Nginx的最大文件描述符，以及worker_rlimit_nofile的最佳值