nginx 并发优化

因为业务当中碰到过业务并发的时候nginx直接挂掉的情况。
所以专门把nginx并发优化的相关文章梳理了一遍。并实践如下。

一： 先解决nginx高并发的一些服务器报错

通过nginx的error日志去拿到报错：

vim /var/log/nginx/xxxx_error.log.3.gz

error.log

可见报错主要为两种：

• 文件描述符不够用。
• worker connection 不够用。

原因如下：

• 文件描述符不够用的情况参考ulimit相关的东西。

• worker connection 不够用的情况参考下面这几篇文章，稍微改几个nginx配置参数就解决掉了。

• worker_connections参数官方文档

• nginx worker_connections are not enough(错误)

先把一些报错处理完后，去分析nginx的瓶颈在哪里。

1 确认cpu是不是瓶颈（top)
2 确认内存是不是瓶颈(free)
3 确认网络连接数是不是瓶颈
关于网络链接这块，需要用到netstat命令：
先通过netstat -ant |grep -w 80 查看各个nginx的tcp连接在并发情况下的状态
明显发现是因为ESTABLISHED 状态的数目过少，一直都没有超过1300。
同时ab命令下的吞吐量指标一直提不上去，一直在5000左右徘徊。
瓶颈发现了，那就靠这个指标去解决瓶颈。

watch -n 0.1 -d " netstat -ant |grep -w  80|grep 'ESTABLISHED'|wc -l"

含义为同时在连接状态的tcp连接数。

因为涉及到tcp参加优化，从内核优化着手。

参考这篇文章：
基于Nginx实现10万+并发，你应该做的Linux内核优化

用ab命令去验证

ab -r -n 100000 -c 10000    http://your.ip/

其他

• file-max与ulimit的关系与差别

ab测试并发的原理

可以看一下ab.c的源代码：
http://svn.apache.org/repos/asf/httpd/httpd/trunk/support/ab.c
重点是static void test(void)函数的实现
ab在执行时会先“同时”建立-c条TCP连接，（如果带-k参数） 然后一直用这-c条连接一直发送请求，在响应时间大于等于-t的超时时间或者所有的-n条请求数已经被发送完毕时，停止发送。
可以验证如下：
client执行ab -r -k -n 100000 -c 1000 http://54.199.226.173/
server 执行watch -n 0.1 -d " netstat -ant |grep -w 80|grep 'ESTABLISHED'|wc -l"
会发现ESTABLISHED状态的连接数永远都是1000条。

有时碰到ab数据不准的情况

原因有以下几点：

• 单机压测

总结

总体思路都比较简单，先排错，再优化
优化过程中一定要有一个指标作为参考。
不要单机压测，单机压测的数据都不准。
本文测试中因为涉及到网络带宽的原因，所以关于数据传输速率相关的数据都不可靠。
最好的情况是内网测内网。