Question

现在在 gunicorn 上运行留言板应用，然后通过 nginx 进行反向代理，返回响应。通过反向代理响应可以将留言板应用的服务器横向扩展成多个。这里我们不进行横向扩展，只评估单一服务器的应用性能。

12.5.1　gunicorn 的设置

gunicorn 可以指定 -D 选项将进程转为守护进程，即守护进程化（Daemonize）（LIST 12.21）。

LIST 12.21　通过 gunicorn 命令将留言板应用转为守护进程并执行

$ gunicorn -w 2 -b 127.0.0.1:8000 -D guestbook

NOTE

守护进程化是指以 Unix 守护进程的形式运行程序。Unix 守护进程运行在后台，并且启动之后不需要用户直接控制。

以 gunicorn 为例，给 gunicorn 命令指定 -D 选项后，gunicorn 便脱离了用户的控制，会转为持续等待请求的后台进程。

12.5.2　nginx 的设置

编辑 nginx 默认站点的设置文件，以反向代理的形式连接在 gunicorn 上运行的应用（LIST 12.22）。

LIST 12.22　/etc/nginx/sites-available/default

# 名为guestbook 的upstream（上游服务器）的设置
upstream guestbook {
  server 127.0.0.1:8000;
}
server {
  listen   80;  # 使用端口80
  server_name  localhost;  # 主机名为localhost
  # 访问日志的文件路径
  access_log  /var/log/nginx/localhost.access.log;
  location / {  # 域名后的路径为/ 时
    # 反向代理到名为guestbook 的upstream
    proxy_pass http://guestbook;
  }
}

upstream 指令里可以设置多个服务器。在一台应用服务器无法满足处理需求时，可以在 upstream 里设置多台应用服务器来分担负荷。

设置文件编辑完成后要记得进行配置测试及重载。

12.5.3　评估 nginx+gunicorn 的性能

接下来用 ApacheBench 评估性能（LIST 12.23）。

LIST 12.23　执行 ab 命令

$ ab -n 1000 -c 100 http://127.0.0.1/

评估结果如下。

Server Software:    nginx/1.4.6
Server Hostname:    127.0.0.1
Server Port:      80
Document Path:      /
Document Length:    7398 bytes
Concurrency Level:    100
Time taken for tests:   2.655 seconds
Complete requests:    1000
Failed requests:    0
Write errors:       0
Total transferred:    7556000 bytes
HTML transferred:     7398000 bytes
Requests per second:  376.61 [#/sec] (mean)
Time per request:     265.529 [ms] (mean)
Time per request:     2.655 [ms] (mean, across all concurrent requests)
Transfer rate:      2778.95 [Kbytes/sec] received
Connection Times (ms)
        min  mean[+/-sd] median   max
Connect:    0  1   3.6    0    14
Processing:  22  252  42.2  264   273
Waiting:     22  252  42.2  264   273
Total:     27  253  39.8  264   286
Percentage of the requests served within a certain time (ms)
  50%  264
  66%  265
  75%  265
  80%  265
  90%  266
  95%  266
  98%  267
  99%  268
 100%  286 (longest request)

与单独由 gunicorn 构成的服务器相比，响应时间略有延长，但考虑到可用多台服务器构成服务器组，这点损失还是可以接受的。

12.5.4　性能比较

最后我们来比较一下改善前和改善后的性能评估结果。评估结果如 LIST 12.24 和 LIST 12.25 所示。

LIST 12.24　改善前的评估结果（精选）

Connection Times (ms)
        min  mean[+/-sd] median   max
Connect:    0  0   1.1    0     5
Processing:  19  466  82.5  489   497
Waiting:     19  466  82.5  489   497
Total:     24  467  81.5  489   497

LIST 12.25　改善后的评估结果（精选）

Connection Times (ms)
        min  mean[+/-sd] median   max
Connect:    0  1   3.6    0    14
Processing:  22  252  42.2  264   273
Waiting:     22  252  42.2  264   273
Total:     27  253  39.8  264   286

从 Flask 的开发服务器换到 nginx 和 gunicorn 组成的服务器之后，Total 的时间比改善前缩短了近一半。响应时间缩短了，因此我们可以认为有改善效果。至此改善工作结束。

NOTE

若想在上述基础上进一步缩短响应时间，可以考虑下述对策。出于篇幅原因，这里就不进行详细说明了。

· 数据库方面将 shelve 换成 MySQL 等REBMS（加快数据库访问速度）

· 在别的机器上运行应用，增加机器数（增加可同时处理的请求数）

· 使用 memcached 等缓存服务器（减少访问数据库的次数）