关于Nginx的一些优化（突破十万并发）

　　一般来说nginx配置文件中对优化比较有作用的为以下几项：workerprocesses8；
　　nginx进程数，建议按照cpu数目来指定，一般为它的倍数。workercpuaffinity0000000100000010000001000000100000010000001000000100000010000000；
　　为每个进程分配cpu，上例中将8个进程分配到8个cpu，当然可以写多个，或者将一个进程分配到多个cpu。workerrlimitnofile102400；
　　这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimitn）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimitn的值保持一致。useepoll；
　　使用epoll的IO模型，这个不用说了吧。workerconnections102400；
　　每个进程允许的最多连接数，理论上每台nginx服务器的最大连接数为workerprocessesworkerconnections。keepalivetimeout60；
　　keepalive超时时间。clientheaderbuffersize4k；
　　客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconfPAGESIZE取得。openfilecachemax102400inactive20s；
　　这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。openfilecachevalid30s；
　　这个是指多长时间检查一次缓存的有效信息。openfilecacheminuses1；
　　openfilecache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive时间内一次没被使用，它将被移除。
　　关于内核参数的优化：net。ipv4。tcpmaxtwbuckets6000
　　timewait的数量，默认是180000。net。ipv4。iplocalportrange102465000
　　允许系统打开的端口范围。net。ipv4。tcptwrecycle1
　　启用timewait快速回收。net。ipv4。tcptwreuse1
　　开启重用。允许将TIMEWAITsockets重新用于新的TCP连接。net。ipv4。tcpsyncookies1
　　开启SYNCookies，当出现SYN等待队列溢出时，启用cookies来处理。net。core。somaxconn262144
　　web应用中listen函数的backlog默认会给我们内核参数的net。core。somaxconn限制到128，而nginx定义的NGXLISTENBACKLOG默认为511，所以有必要调整这个值。net。core。netdevmaxbacklog262144
　　每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。net。ipv4。tcpmaxorphans262144
　　系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的DoS攻击，不能过分依靠它或者人为地减小这个值，更应该增加这个值（如果增加了内存之后）。net。ipv4。tcpmaxsynbacklog262144
　　记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M内存的系统而言，缺省值是1024，小内存的系统则是128。net。ipv4。tcptimestamps0
　　时间戳可以避免序列号的卷绕。一个1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种异常的数据包。这里需要将其关掉。net。ipv4。tcpsynackretries1
　　为了打开对端的连接，内核需要发送一个SYN并附带一个回应前面一个SYN的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送SYNACK包的数量。net。ipv4。tcpsynretries1
　　在内核放弃建立连接之前发送SYN包的数量。net。ipv4。tcpfintimeout1
　　如果套接字由本端要求关闭，这个参数决定了它保持在FINWAIT2状态的时间。对端可以出错并永远不关闭连接，甚至意外宕机。缺省值是60秒。2。2内核的通常值是180秒，2你可以按这个设置，但要记住的是，即使你的机器是一个轻载的WEB服务器，也有因为大量的死套接字而内存溢出的风险，FINWAIT2的危险性比FINWAIT1要小，因为它最多只能吃掉1。5K内存，但是它们的生存期长些。net。ipv4。tcpkeepalivetime30
　　当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时。
　　下面贴一个完整的内核优化设置：net。ipv4。ipforward0net。ipv4。conf。default。rpfilter1net。ipv4。conf。default。acceptsourceroute0kernel。sysrq0kernel。coreusespid1net。ipv4。tcpsyncookies1kernel。msgmnb65536kernel。msgmax65536kernel。shmmax68719476736kernel。shmall4294967296net。ipv4。tcpmaxtwbuckets6000net。ipv4。tcpsack1net。ipv4。tcpwindowscaling1net。ipv4。tcprmem4096873804194304net。ipv4。tcpwmem4096163844194304net。core。wmemdefault8388608net。core。rmemdefault8388608net。core。rmemmax16777216net。core。wmemmax16777216net。core。netdevmaxbacklog262144net。core。somaxconn262144net。ipv4。tcpmaxorphans3276800net。ipv4。tcpmaxsynbacklog262144net。ipv4。tcptimestamps0net。ipv4。tcpsynackretries1net。ipv4。tcpsynretries1net。ipv4。tcptwrecycle1net。ipv4。tcptwreuse1net。ipv4。tcpmem94500000915000000927000000net。ipv4。tcpfintimeout1net。ipv4。tcpkeepalivetime30net。ipv4。iplocalportrange102465000
　　下面是一个简单的nginx配置文件：userwwwwww；workerprocesses8；workercpuaffinity00000001000000100000010000001000000100000010000001000000；errorlogwwwlognginxerror。logcrit；pidusrlocalnginxnginx。pid；workerrlimitnofile204800；events｛useepoll；workerconnections204800；｝http｛includemime。types；defaulttypeapplicationoctetstream；charsetutf8；servernameshashbucketsize128；clientheaderbuffersize2k；largeclientheaderbuffers44k；clientmaxbodysize8m；sendfileon；tcpnopushon；keepalivetimeout60；fastcgicachepathusrlocalnginxfastcgicachelevels1：2keyszoneTEST：10minactive5m；fastcgiconnecttimeout300；fastcgisendtimeout300；fastcgireadtimeout300；fastcgibuffersize4k；fastcgibuffers84k；fastcgibusybufferssize8k；fastcgitempfilewritesize8k；4fastcgicacheTEST；fastcgicachevalid2003021h；fastcgicachevalid3011d；fastcgicachevalidany1m；fastcgicacheminuses1；fastcgicacheusestaleerrortimeoutinvalidheaderhttp500；openfilecachemax204800inactive20s；openfilecacheminuses1；openfilecachevalid30s；tcpnodelayon；gzipon；gzipminlength1k；gzipbuffers416k；gziphttpversion1。0；gzipcomplevel2；gziptypestextplainapplicationxjavascripttextcssapplicationxml；gzipvaryon；server｛listen8080；servernamebackup。aiju。com；indexindex。phpindex。htm；rootwwwhtml；locationstatus｛stubstatuson；｝location。。（phpphp5）？｛fastcgipass127。0。0。1：9000；fastcgiindexindex。php；includefcgi。conf；｝location。。（gifjpgjpegpngbmpswfjscss）5｛expires30d；｝logformataccessremoteaddrremoteuser〔timelocal〕requeststatusbodybytessenthttprefererhttpuseragenthttpxforwardedfor；accesslogwwwlogaccess。logaccess；｝｝
　　关于FastCGI的几个指令：fastcgicachepathusrlocalnginxfastcgicachelevels1：2keyszoneTEST：10minactive5m；
　　这个指令为FastCGI缓存指定一个路径，目录结构等级，关键字区域存储时间和非活动删除时间。fastcgiconnecttimeout300；
　　指定连接到后端FastCGI的超时时间。fastcgisendtimeout300；
　　向FastCGI传送请求的超时时间，这个值是指已经完成两次握手后向FastCGI传送请求的超时时间。fastcgireadtimeout300；
　　接收FastCGI应答的超时时间，这个值是指已经完成两次握手后接收FastCGI应答的超时
　　时间。fastcgibuffersize4k；
　　指定读取FastCGI应答第一部分需要用多大的缓冲区，一般第一部分应答不会超过1k，由于页面大小为4k，所以这里设置为4k。fastcgibuffers84k；
　　指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答。fastcgibusybufferssize8k；
　　这个指令我也不知道是做什么用，只知道默认值是fastcgibuffers的两倍。fastcgitempfilewritesize8k；
　　在写入fastcgitemppath时将用多大的数据块，默认值是fastcgibuffers的两倍。fastcgicacheTEST
　　开启FastCGI缓存并且为其制定一个名称。个人感觉开启缓存非常有用，可以有效降低CPU负载，并且防止502错误。fastcgicachevalid2003021h；6fastcgicachevalid3011d；fastcgicachevalidany1m；
　　为指定的应答代码指定缓存时间，如上例中将200，302应答缓存一小时，301应答缓存1天，其他为1分钟。fastcgicacheminuses1；
　　缓存在fastcgicachepath指令inactive参数值时间内的最少使用次数，如上例，如果在5分钟内某文件1次也没有被使用，那么这个文件将被移除。fastcgicacheusestaleerrortimeoutinvalidheaderhttp500；
　　不知道这个参数的作用，猜想应该是让nginx知道哪些类型的缓存是没用的。以上为nginx中FastCGI相关参数，另外，FastCGI自身也有一些配置需要进行优化，如果你使用phpfpm来管理FastCGI，可以修改配置文件中的以下值：valuenamemaxchildren60value
　　同时处理的并发请求数，即它将开启最多60个子线程来处理并发连接。valuenamerlimitfiles102400value
　　最多打开文件数。valuenamemaxrequests204800value
　　每个进程在重置之前能够执行的最多请求数。
　　下面贴几张测试结果图。
　　静态页面为我在squid配置4W并发那篇文章中提到的测试文件，下图为同时在6台机器运行webbenchc30000t600http：backup。aiju。com：8080index。html命令后的测试结果：
　　使用netstat过滤后的连接数：
　　php页面在status中的结果（php页面为调用phpinfo）：
　　php页面在netstat过滤后的连接数：
　　未使用FastCGI缓存之前的服务器负载：
　　此时打开php页面已经有些困难，需要进行多次刷新才能打开。上图中cpu0负载偏低是因为测试时将网卡中断请求全部分配到cpu0上，并且在nginx中开启7个进程分别制定到cpu17。
　　使用FastCGI缓存之后：
　　此时可以很轻松的打开php页面。
　　这个测试并没有连接到任何数据库，所以并没有什么参考价值，不过不知道上述测试是否已经到达极限，根据内存和cpu的使用情况来看似乎没有，但是已经没有多余的机子来让我运行webbench了。囧