uwsgi在设置最大连接数的时候，如果直接设置如下：

listen = 65535

    那么在重启uwsgi的时候会报错，如下：

Listen queue size is greater than the system max net.core.somaxconn (128).

    意思是：监听的队列大小大于了系统配置的最大值128。也就是说，我们uwsgi最大只能监听128个连接，如果超过这个数量，则无法响应额外的请求了。
    如果应用的请求确实很大，需要监听超过128个连接，那么我们就需要突破最大监听128个连接的“魔咒”！

    突破需要从三方面着手：系统、nginx和uwsgi
1.系统
    如果系统级不提供支持，其他操作都是白搭的。系统是基础支持，所以我们先要让系统的最大监听连接数扩大。
    我们需要修改的文件是：/etc/sysctl.conf
    我们在这个文件里加入一个配置项：

net.core.somaxconn = 65535

    然后保存这个配置修改。如果事先已经存在这个选项，则修改连接数，如果没有就添加。此修改请使用管理员权限执行。
    修改完后，并没有生效哦。请在命令行下执行下面语句来将修改的配置生效：

sysctl -p

    这样，系统的基础支持就生效了。

2.nginx
    nginx作为请求转发的一级，如果没有提高请求的大小，uwsgi设置的再大，也只能收到nginx允许的最大连接数。所以我们要修改nginx的最大连接数。
    确保下面的配置存在或者正确：

worker_rlimit_nofile 65535; # 最大打开文件数，这个值需要<= worker_connections
events {
    worker_connections  65535;
}

    这个数字就是连接数。自己看情况修改吧。没有的话，就添加。

3.uwsgi
    这是我们的终点站，我们要让我们的uwsgi的最大监听的连接数变大，就要将uwsgi的配置修改变大。因为系统基础支持已经设置好了，那么现在设置超过128的连接数，就可以行了。
    uwsgi的设置如下：

listen         = 65535
max-requests = 65535  

    前两个是需要的选项，后两个是备用的。因为如果连接数变大后，线程不够，也是处理不过来的。线程数根据系统的CPU来设定，一般是CPU数翻一倍比较好。不过具体效果看测试结果。
    配置好后，重启一下uwsgi，设置就生效了，监听的连接数也变大了。