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 做优化处理,现在我们只是完成了压力测试和它的统计信息的观察。那么在下一篇文章,我们将在这个基础上,针对这个压力测试结果做优化。

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180125A10F0T00?refer=cp_1026

相关快讯

扫码关注云+社区