本文目录导航：
如何修正nginx的最大衔接数
修正nginx的最大衔接数方法如下：1、worker rlimit nofile用于指定一个nginx进程可以关上的最多文件形容符数目，这里是，须要经常使用命令ulimit来设置。
2定义Nginx每个进程的最大衔接数，自动是1024数值。
最大客户端衔接数由worker processes选择，在作为反向代理时，进程的最大衔接数受Linux系统进程的最大关上文件数限度，须要在口头操作系统命令ulimitn后点击worker connections运转。
3、一个nginx进程最多可以接受多少客户端同时来启动衔接，并且这个进程可以关上的最多文件数，客户衔接数无法超越客户端可衔接量。
4、控制Nginx单个进程准许的最大衔接数的参数为worker connections，参数依据主机性能和内存经常使用量来调整后，即可修正最大衔接数。
nginx能扛得住5万并发，那更大呢，怎样办
在高并发衔接的状况下，Nginx是Apache主机不错的代替品。
Nginx同时也可以作为7层负载平衡主机来经常使用。
测试结果，Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 可以接受3万以上的并发衔接数，相当于等同环境下Apache的10倍。
依据阅历，4GB内存的主机+Apache（prefork形式）普通只能解决3000个并发衔接，由于它们将占用3GB以上的内存，还得为系统预留1GB的内存。
我曾经就有两台Apache主机，由于在性能文件中设置的MaxClients为4000，当Apache并发衔接数到达3800时，造成主机内存和Swap空间用满而解体。
而这台 Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 主机在3万并发衔接下，开启的10个Nginx进程消耗150M内存（15M*10=150M），开启的64个php-cgi进程消耗1280M内存（20M*64=1280M），加上系统自身消耗的内存，总共消耗不到2GB内存。
假设主机内存较小，齐全可以只开启25个php-cgi进程，这样php-cgi消耗的总内存数才500M。
在3万并发衔接下，访问Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 主机的PHP程序，依然速度飞快。
你说的5万可以成功最高能到达10万并发 然而有一个疑问你的主机性能要跟得上才可以玩要不然弄到那个并发数也没啥意义
nginx能支持多少长衔接
一 前言当治理少量衔接时，特意是只要大批生动衔接，NGINX有比拟好的CPU和RAM应用率，当初是多终端坚持在线的时代，更能让NGINX施展这个好处。
本文做一个便捷测试，NGINX在一个普通PC虚构机上保养100k的HTTP长衔接，而后检查NGINX和系统的资源应用率。
二 测试环境1.服务端配件：双核2.3GHz，2GB内存软件：CentOS 6.5, kernel 2.6.32,gcc 4.4.7, nginx 1.4.7IP：10.211.55.8内核参数调整：$ /sbin/sysctl -w _conntrack_max= # 优化系统全体衔接数$ /sbin/sysctl _conntrack_max #验证能否失效NGINX从源码编译时带--with-http_stub_status_module，只列出与自动设置不同的局部：worker_rlimit_nofile ;events {worker_connections;}http {# 设一个比拟大得超时，客户端能以陡峭的形式发送HEAD恳求来维持KeepAlivekeepalive_timeout3600;#监控衔接数，本机访问location /nginx_status {stub_status on;access_log off;allow 127.0.0.1;deny all;}}2. 客户端1配件：双核2.3GHz，2GB内存软件：CentOS 6.5, kernel 2.6.32, gcc 4.4.7, Python 3.3.5IP：10.211.55.9内核参数调整：$ /sbin/sysctl -w _local_port_range=1024 ” #实践只经常使用个端口$ /sbin/sysctl _local_port_range #验证能否失效$ vi /etc/security/ #优化以后用户的最大关上文件数nofile（hard >= soft > ）$ ulimit -n #验证能否失效，或者需重启shellPython 3.3.5从源码编译，如下性能：$ pyvenv ~/pyvenv #创立虚构环境，便于测试$ . ~/pyvenv/bin/activate #激活虚构环境(pyvenv) $ python #从pip官方下载(pyvenv) $ pip install asyncio #装置异步IO模块由于Apache ab只能批量恳求，不能维持衔接，所以自己写了一个HTTP长衔接测试工具基本用法：(pyvenv) $ python --helpusage: [-h] [-c CONNECTIONS] [-k KEEPALIVE] urlasynclipositional arguments:url page addressoptional arguments:-h, --helpshow this help message and exit-c CONNECTIONS, --connections ConNECTIONSnumber of connections simultaneously-k KEEPALIVE, --keepalive KEEPALIVEHTTP keepalive timeout上班机制：每隔10毫秒延续创立10个衔接（每秒约1000个衔接），直到总衔接数到达CONNECTIONS，每个衔接都会睡眠[1, KEEPALIVE / 2]的一个随机数（单位为秒），而后向服务端url发送一个HEAD恳求来维持HTTP KeepAlive，而后重复上一个睡眠步骤。
。
。
3. 客户端2与客户端1齐全分歧，除了IP为10.211.55.10三 运转与输入1. 服务端系统闲暇# vmstatprocs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----rb swpd free buffcache si sobibo in cs us sy id wa st000 1 26 2800 . 服务端启动NGINX，无外部WEB恳求# nginx# vmstatprocs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----rb swpd free buffcache si sobibo in cs us sy id wa st000 1 24 2500 3. 客户端1和2先后启动，每个客户端动员个长衔接，并维持直到服务端封锁或超时。
(pyvenv) $ python -c -k 3600&4. 约2小时后。
。
。
检查服务端# curlconnections: server accepts handled requests Reading: 0 Writing: 1 Waiting: # ps -p 1899 -o pid,%cpu,%mem,rss,commPID %CPU %MEM RSS COMMAND.04.9 nginx# vmstat 3procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----rb swpd free buffcache si sobibo in cs us sy id wa st000 6 0 0 9900^C# freetotal used free sharedbuffers cachedMem: 576 2 -/+ buffers/cache Swap8760四 总结1. NGINX平均每个衔接的内存占用很小，经过ps的rss看出，每个衔接物理内存占用约1k。
少数内存都被内核TCP缓存占用。
2. NGINX维持少量衔接（大批生动衔接，本文中平均每秒生动衔接为总衔接数的千分之一）占用很少CPU，上文仅为2%。
3. 最好的优化就是不优化。
整个测试除了优化文件数和衔接数的这些硬限度外，没有任何参数调优，但细心计算下就发现平均每个衔接内存占用不到10k，远小于自动的缓存大小（_rmem = 4096 ）和 （_wmem = 4096 ）4. NGINX维持此类衔接的重要瓶颈就是可用内存大小，我的2GB内存虚构机其实可以支持15万长衔接，只不过我物理机器没有内存再继续clone虚构机客户端了:-(5. 只管会遇到更多内核参数的限度，但大内存主机支持100万衔接是齐全没疑问的。
