文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

虽然NGINX相对于其他web 服务器来说尚显年轻,但是它在业界迅速地流行了起来,它的成功,部分原因是它为寻找轻量级高性能web服务器的人群提供了一个很好的选择。

在今天的文章里,我们将谈谈怎样把一个刚安装完成的 NGINX 实例,通过调整和设置,让它在原本高性能的基础上锦上添花。 虽然这不是一篇完整的调优指南,但是通过阅读本文,读者将会对基础层面上的调优方式和常用的NGXINX调优参数有一个整体的认识。

进入调优之前, 首先让我们安装NGINX。

第 1 段(可获 1.28 积分)

安装NGINX

在本文,我们在Ubuntu(一个基于Linux的服务器)上运行NGINX,可以使用以下apt-get 命令执行安装。

root@nginx-test:~# apt-get install nginx

上述命令会执行一次通用的NGINX安装,并且有些调优化参数已经给你设置好了。不过也就这样了,这个默认状态下安装的NGINX不提供太多优化相关的内容。为了找一个真实的web应用来调优,我们可以从 Github 获取代码,在本地部署一个简单的网站进行实验,让我们开始吧。

root@nginx-test:~# git clone https://github.com/BlackrockDigital/startbootstrap-clean-blog.git /var/www/html
Cloning into '/var/www/html'...
remote: Counting objects: 308, done.
remote: Total 308 (delta 0), reused 0 (delta 0), pack-reused 308
Receiving objects: 100% (308/308), 1.98 MiB | 0 bytes/s, done.
Resolving deltas: 100% (119/119), done.
Checking connectivity... done.
第 2 段(可获 1.04 积分)

在进行性能调优时,很重要的一点就是要知道目标应用的类型,对 NGINX 来说,就是了解你的调优目标是静态的内容呢,还是下游提供的动态内容。两种内容类型的之间差异会影响调整的参数和参数的值。

在这篇文章,虽然我们只对 NGINX 做静态 HTML 内容服务进行调优,但是大部分的参数对一般情况下的 NGINX 仍然适用,当然也并非全部。本文可以作为你调优和测试的参考指南。

第 3 段(可获 1.36 积分)

现在我们已经安装了最基本的NGINX实例,部署了一个样例站点,下面让我们看一下这个开箱即用的NGINX的性能吧。

建立测试基线

无论什么调优,首先要做的就是建立测量的方式和单位,在这篇文章里,我们使用 HTTP 负载能力测试工具 ApacheBench, 又称 ab ,为NGINX系统做流量测试。

这个负载测试工具对web应用的测试非常简单而有效。针对不同类型的测试场景,ApacheBench提供相当丰富的选项,不过在这篇文章里, 我们要做的测试非常简单。

 

第 4 段(可获 1.25 积分)

我们要执行的 ab 命令有两个参数,-c(并发级数),-n(请求数)

$ ab -c 40 -n 50000 http://159.203.93.149/

执行这条命令时,我们将并发级数( -c 参数)设置成40,意味着 ab 至少会跟我们的NGINX实例保持40个并行的HTTP会话,与此同时我们还使用 -n 参数限制了请求的总数,从本质上来说,这两个参数结果是 ab 会以跟NGINX保持每次 40 个并发 的HTTP会话数量,发送尽可能多的请求到服务器,直至请求总数达到50000个。

第 5 段(可获 1 积分)

让我们继续,执行一个测试运行,建立一个基准,并确定我们将使用测试使用的度量.

# ab -c 40 -n 50000 http://159.203.93.149/
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 159.203.93.149 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        nginx/1.10.0
Server Hostname:        159.203.93.149
Server Port:            80

Document Path:          /
Document Length:        8089 bytes

Concurrency Level:      40
Time taken for tests:   16.904 seconds
Complete requests:      50000
Failed requests:        0
Total transferred:      420250000 bytes
HTML transferred:       404450000 bytes
Requests per second:    2957.93 [#/sec] (mean)
Time per request:       13.523 [ms] (mean)
Time per request:       0.338 [ms] (mean, across all concurrent requests)
Transfer rate:          24278.70 [Kbytes/sec] received
第 6 段(可获 0.3 积分)

在上面的输出中,有几个有趣的指标。现在我们将关注Requests per second指标。这个指标表示我们的NGINX支持的每秒平均请求数。 当我们调整参数后,我们可以看到这个指标值会发生变化。

Requests per second:    2957.93 [#/sec] (mean)

如上,我们看到每秒的请求数是2957.93。 这个数值看起来很高了,但是我们会让这个数值继续增加。

当我们做性能调整时,最重要的是做一个小的改变后就和基线进行对比。本文中,每秒2957.93个请求就是我们测量的基线。对于一个成功的调参,它必是增加每秒处理请求数。

第 7 段(可获 1.55 积分)

带着我们的基线指标集,我们开始调优NGINX。

工作线程

NGINX最基础的一个参数就是可用的工作线程数。默认下,这个参数的值是auto,即NGINX会按照系统上CPU个数的工作线程。

对于大多数系统,一个CPU一个工作线程是性能均衡的、小负载的。本文中,我们试图利用NGINX服务静态内容应该是低CPU的特点。让我们看看增加这个参数值能获取多少每秒请求数。

第 8 段(可获 1.41 积分)

第一个测试,我们为每一个CPU设置为两个工作进程。

为了找出我们需要多少工作进程,我们首先需要知道有多少可用的CPU。有很多方式来获取可用CPU数,在本例中我们使用lshw命令查看硬件信息。

root@nginx-test:~# lshw -short -class cpu
H/W path      Device  Class      Description
============================================
/0/401                processor  Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
/0/402                processor  Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GH
第 9 段(可获 0.79 积分)

从上面的输出可看到我们的系统上有2个CPU。这就意味着在我们的第一个测试中,可以设置4个工作进程。

我们编辑/etc/nginx/nginx.conf文件中的参数worker_processes 。这是NGINX 默认配置文件,今天我们将会调整的参数都在这个文件中。

worker_processes auto;

从上面看到这个参数的默认值是 auto。现在我们把它修改为4。

worker_processes 4;

修改完后需要保存/etc/nginx/nginx.conf 文件,为了让配置修改生效我们需要重启NGINX 。

第 10 段(可获 1.38 积分)
root@nginx-test:~# service nginx restart
root@nginx-test:~# ps -elf | grep nginx
1 S root     23465     1  0  80   0 - 31264 sigsus 20:16 ?        00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
5 S www-data 23466 23465  0  80   0 - 31354 ep_pol 20:16 ?        00:00:00 nginx: worker process
5 S www-data 23467 23465  0  80   0 - 31354 ep_pol 20:16 ?        00:00:00 nginx: worker process
5 S www-data 23468 23465  0  80   0 - 31354 ep_pol 20:16 ?        00:00:00 nginx: worker process
5 S www-data 23469 23465  0  80   0 - 31354 ep_pol 20:16 ?        00:00:00 nginx: worker process
0 S root     23471 23289  0  80   0 -  3628 pipe_w 20:16 pts/0    00:00:00 grep --color=auto nginx
root@nginx-test:~#

从上面可以看到有4个运行的进程,名称为nginx: worker process。这表明我们的修改是成功的。

检查效果

随着我们开启额外的工作进程后,我们再运行一次ab看看输出是否有任何变化。

# ab -c 40 -n 50000 http://159.203.93.149/ | grep "per second"
Requests per second:    3051.40 [#/sec] (mean)

看来我们的改变影响非常小:  Requests per second 原先是2957.93,新值为3051.40。 就只多了100左右。 虽然这是一个进步,这不是我们期望的大变化。

第 11 段(可获 1.1 积分)
worker_processes 8;

让我们继续修改 worker_processes 参数的值为8,为CPU个数的4倍。为了检验修改是否有效,我们需要再次重启NGINX 服务。

root@nginx-test:~# service nginx restart

服务重启后,我们再次运行ab 测试。

# ab -c 40 -n 50000 http://159.203.93.149/ | grep "per second"
Requests per second:    5204.32 [#/sec] (mean)

看起来,8个工作线程比4个影响更大些。对比我们的基线指标,我们可以看到8个工作线程大概提升了2250每秒请求。

第 12 段(可获 1.01 积分)

总的来说似乎比我们的基线数据明显改善了,现在的问题在于,如果我们进一步增加工作线程数,还能改善多少?

记住,最好方式是一步一步地,每次做一些小的增量变化,然后测量性能是否增加。 对于这个参数,我每次以2的倍数递增,然后重新运行测试。重复这个过程直到每秒请求数的值不再增加。然而对于本文来说,就先到此为止了,暂时把worker_processes的值设置成8,接下来我们来研究下一个参数。

准备好迎接第二部分了吗? 明天再过来看看这个 链接 吧 !

第 13 段(可获 1.39 积分)

文章评论