Nginx 之大并发服务器架构实战技法二

在上一篇文章里，我介绍了一下nginx服务器解决大并发的基本思路，现在我就要运用这些理论知识，一起来看看实际效果咋样。我们总体目标是，把一台普通的PC机nginx服务器单机，在不用其他架构和手段的情况下，单使用我们上次的理论把他优化成1万并发以上。

Nginx 之大并发服务器架构实战技法二

首先，来对这台 nginx 服务器做一下压力测试。在这里压力测试我们使用使用apache自带的ab小工具。我们先测试一下nginx 的并发性咋样。先来1000个并发，测试50000 的请求。测试结果如下图所示：

1000个并发500000个请求的测试结果

1000个并发，有3721个报错信息

通过结果显示80%是在100毫秒内相应。90%-95%是在1秒左右相应，其中有1%超过了3秒。5万个请求，有3000多个出错。这个请求情况并不算优秀。

再压一次2000个并发，8万个请求，压力测试结果显示如下：

2000个并发情况下的报错

2000并发90%都在3秒以上响应

通过上面的测试结果，我们看到出问题了。有一个报错： “socket: Too many open files”，而且90以上都是在3秒以上响应。所谓高并发，没有什么神奇的东西。只要你服务器硬盘快。CPU强，内存大。硬件条件要够。这个和比武一样，首先要有硬件条件，然后才能讲技巧。具体到我们这里，我们的硬件够，2000个并发应该不是问题，但是此处确提示："socket: Too many open files",其实这个报错就是我们优化的一个重要的启发。它说打开的文件太多了。我们知道，在linux 中，简介即是美，一切的操作，无论硬盘，软盘还是打印机等都当成是文件来处理。其实质是，每来一个请求，都要建立一个socket 连接，在linux 看来，就是把网卡看成了一个文件。1000多个并发，打开了1000多次次，打开的太多了。接收不了，所以报"Too many open files"错误。

对于nginx 服务器，默认情况下，只允许打开1024个描述符。做高并发服务器，一下就用光了。所以我们需要把服务器允许打开的描述符变大些，调节成2000.： “ulimit -n 2000”,ab再 测试一下。

修改允许打开的描述符截图

结果发现，发现80000的请求，70000多个请求失败，那么这时候，基本上2000个并发的测试已经是撑不住了。

在刚才的测试中，看结果显示，有多少个等待的。什么叫等待呢？就类似学生去食堂买饭，好多人在等着买饭。

我们当然是希望等待越少越好。

压力测试显示等待的队列

工欲善其事，必先利其器。我们用ab小工具压2000，发现也可以压。但是我们想更详细的观察服务器的状态。比方说当前有多少客户端正在连接中、并发是多少，有多少处于等待状态。所以我们要借助与nginx 的一个统计工具来方便我们做测试。有一个选项是内建的一个nginx 的观察统计模块模块：--with-http_stub_status_module，在编译nginx 的时候，只需要指定一下就可以了。便于我们观察每时每刻到底有多少并发，多少等待。这样便于我们调优。

统计模块配置

在浏览器上观察统计模块，初始情况下我们可以看到，当前活动连接有一个，已经接收的连接、正在等待的请求有0个，

我们现在在压力测一下。2000个并发，请求10万次，通过 观察统计模块，我们发现显示的有点异样。我们请求的是

2000个并发，但是这里显示，最多只有600多并发的样子。在看看ab 的结果，10万个并发，9万多的失败率。这个结果基本上就没法接受了。

2000个并发，通过统计观察最多只有几百的并发，这这里是134个并发

2000并发10万求情的失败率显示

nginx 不尽人意，2000个并发就错误率非常高了。那么失败没有关系，正因为它失败了。而且并发低，才需要我们做优化。在这里，我们还没有对nginx 做优化处理，现在我们只是完成了压力测试和它的统计信息的观察。那么在下一篇文章，我们将在这个基础上，针对这个压力测试结果做优化。