Question

本节，我们将对第 2 章中开发的应用进行性能评估，然后学习如何让该应用在 nginx 和 gunicorn 上运行。

12.2.1　什么是应用的性能

我们总是会说“应用的性能好 / 不好”，但好与不好究竟指的是什么呢？下面是几个性能好的例子。

· 应用的处理能力强

· 内存占用量小

· 页面显示速度快

· 通信响应速度快

这些评价对象都不相同，评价中使用的词语也是强、小、快，各不一样。可见，应用的性能有多个指标。所以在谈论性能时，必须首先确定是哪方面性能，不然理解上就会出现偏差。

在 Web 应用的各项性能指标中，本章将重点研究从发送 HTTP 请求到返回响应的这段时间（即响应时间）。响应时间越短，浏览器切换页面的速度就越快，用户就会觉得应用越流畅。另外，我们在评估性能时将使用 ApacheBench（ab 命令）。这是一款基准测试工具，能简单地检测应用的响应时间和请求成功率。

12.2.2　安装 ApacheBench

ApacheBench 是 Web 服务器 Apache 附带的工具之一。通过 apt 进行安装时，要安装 apache-utils（LIST 12.1）。

LIST 12.1　通过 apt 进行安装

$ sudo apt-get install apache2-utils

安装完后就能使用 ab 命令了。本章使用的是 ApacheBench 的 2.3 版本。

12.2.3　用 ApachBench 评估性能

这里运行第 2 章中开发的应用，用 ab 命令检测响应时间。这里以留言板首页的响应速度为检测对象。我们希望在已提交数据的状态下进行检测，因此事先输入了 50 条数据。另外，应用的运行环境如下。

OS	Ubuntu 14.04（64bit 版）
CPU	Intel Core 2 Duo 2.2GHz（双核）
内存	512MB

检测前先启动应用服务器（LIST 12.2）。

LIST 12.2　启动应用

$ python guestbook.py
 * Running on http://127.0.0.1:8000/
 * Restarting with reloader

使用 screen 命令的情况下会弹出新窗口，在新窗口中执行 ab 命令。不使用 screen 命令时则需要按 Ctrl+Z 键，将运行中的应用移至后台，然后再执行 ab 命令。

应用可以通过 IP 地址 127.0.0.1、端口号 8000 访问，所以 ab 命令要指定这个 URL（LIST 12.3）。-n 选项可以指定请求次数，-c 选项可以指定连接数。这里我们把总计 1000 次请求分 100 个连接并行发送。

LIST 12.3　执行 ab 命令

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

检测结束后会输出如 LIST 12.4 所示的报告。

Server Software:    Werkzeug/0.9.6
Server Hostname:    127.0.0.1
Server Port:      8000
Document Path:      /
Document Length:    7398 bytes
Concurrency Level:    100
Time taken for tests:   4.911 seconds
Complete requests:    1000
Failed requests:    0
Write errors:       0
Total transferred:    7554000 bytes
HTML transferred:     7398000 bytes
Requests per second:  203.61 [#/sec] (mean)
Time per request:     491.146 [ms] (mean)
Time per request:     4.911 [ms] (mean, across all concurrent requests)
Transfer rate:      1501.99 [Kbytes/sec] received
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
Percentage of the requests served within a certain time (ms)
  50%  489
  66%  490
  75%  491
  80%  491
  90%  492
  95%  496
  98%  497
  99%  497
 100%  497 (longest request)

接下来了解一下检测结果中需要注意的地方。

◉ Complete requests

Complete requests 部分显示了请求成功与失败的情况。通过上面的例子，我们可以看到，1000 个请求全部成功。如果请求没有全部成功，表示可能超出了 Web 服务器的处理能力。

Complete requests:    1000
Failed requests:    0

◉ Requests per second

1 秒处理的请求数。下述结果表示每秒大约处理 203 个请求。

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

◉ Connection Times

Connection Times 部分可以查看处理 1 个请求所需的连接时间（Connect ）、处理时间（Processing ）、等待时间（Waiting ），单位精确到毫秒。各列元素分别代表最小值（min ）、平均值（mean ）、标准差（[+/-sd] ）、中间值（median ）、最大值（max ）。如果某个时间存在明显的不平均现象，证明应用的某个部分有可能存在瓶颈。

以下述执行结果为例，我们是在本地环境中连接本地的 Web 应用，所以连接时间非常短。另外，处理时间和等待时间都没有明显的不平均现象，证明应用中不存在瓶颈。

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

我们的这个留言板应用直接使用了 Flask 内置的 HTTP 服务器。该内置 HTTP 服务器由 Python 标准模块的 HTTPServer 类扩展而来。这个服务器并不算特别慢，但如果导入更高速的 Python 专用应用服务器，将能明显改善响应性能。

接下来我们将导入 gunicorn，看看这个 Python 的面向 Web 应用的 HTTP 服务器是如何改善响应性能的。

NOTE

本章用 ApacheBench 评估了应用的性能，但要注意，这与 Web 应用实际运作时的情况不完全相同。

ApacheBench 的评估对象是单一URL，但一般的 Web 应用除HTML 以外还需要对图片、CSS、JavaScript 文件发送请求。要获取某 URL 页面中的所有元素，有时需要几十个请求。因此各位要记住，ab 命令检测出的响应性能与用户体感的响应时间之间是存在差异的。