原文在此：http://ziutek.github.com/web_bench/
由于是早上看到 鱼哥，在推上的推荐，我实在忍不住……这是中午的草率之举，所以 鱼哥 对本文的翻译负全责。
PS：别说我工作状态不饱满，我在等丫的程序执行完……
————翻译分割线————
Go 和 Python Web 服务器性能对比
我通常使用 Python 来构建 Web 应用。一年前，在兴趣的驱使下，我开始学习 Go。 在此期间，我重写了一些原本由 C 开发的 CGI 应用，包括运行于 chroot 环境下的同 thttpd 服务器一起的应用。我开始寻找可以开发易于 chroot、且内置 Web 服务器的独立 Web 应用的工具。那时，我开始玩 web.go 框架、mustache.go 模板、Go 原生 http 包和 GoMySQL 数据库 API。我发现，有 http、mustache.go GoMySQL 包的 Go 可以是我用来工作的不错的工具组合。因此，我决定使用 Go 编写我的应用。
在工作过程中发现，我需要比 mustache.go 更加灵活，比 GoMySQL 更加成熟、没有那么多 Bug 的东西。最终，我使用 Kasia.go 模板和 MyMySQL （为我的应用定制开发的包，不过我将其贡献给了 Go 社区）。重写的应用即便是在比以前的负载更高的运营环境下，也工作得很好。我开始思考这个问题：用 Go 实现独立 Web 应用比 Python 到底快了（或者是慢了）多少。我决定做一些各种框架和服务器不同的用途的测试。为了比较，我选择了下面的 Go 包：
- 原始的 Go http包；
- web.go 框架（它使用运行于独立模式[standalone mode] 的 http 包）；
- twister 框架 （它同样使用 http 包）。
和下面的 Python Web服务器/框架：
- 使用 CherryPy WSGI 服务器的 web.py 框架；
- 使用 flup FastCGI 做 nginx 服务器的后台处理的 web.py 框架；
- tornado 异步服务器/框架；
- nginx 做负载均衡的 tornado。
每一个用例，我都编写了一个小应用，略微复杂一些的、传统的 Hello World 例子。任何应用都包括：
- 使用正则表达式通过 URL 路径传递参数；
- 使用语句创建多行输出；
- 使用 printf 形式的格式化函数/表达式格式化输出。
我想，这些都是在 Web 应用中常见的操作，所以应当包含在任何简易的性能对比测试中。所有测试应用的代码在下面的链接中：
测试环境
测试环境包括两台 使用千兆以太网链接的PC （请求发起者和应用服务器）。
- 请求发起者：2 x Xeon 2.6 GHz with hyperthreading, Debian SID, kernel: 2.6.33.7.2-rt30-1-686 #1 SMP PREEMPT RT；
- 服务器: MSI Netbook with two core Intel U4100 1.30GHz, AC power connected, 64-bit Ubuntu 10.10, kernel: 2.6.35-25-generic #44-Ubuntu SMP, Python 2.6.6-2ubuntu2, web.py 0.34-2, flup 1.0.2-1, tornado 0.2-1, nginx 0.7.67-3ubuntu1；
为了产生 HTTP 请求并且评估测试应用的性能，我使用 siege 性能测试工具。Siege 可以用多线程模拟多个用户。我使用了下面的命令产生请求：
siege -c 200 -t 20s http://SERVER_ADDR:8080/Hello/100
或者多个类似的命令，减少参数 -c 的量（在这个测试中，我同时运行了多个 Python 脚本）。它模拟了 200 用户的请求，并持续 20 秒。这个 URL 使得 Web 应用对每个请求都输出 100 行。Go 应用使用 Go 发布版 2011-02-01.1。
结果
GOMAXPROCS=1, 一个 Python 进程：
| 框架 | 请求速率 [1/sec] | |
|---|---|---|
| Go http | 1350 | |
| Twister | 1324 | |
| Web.go | 1141 | |
| Tornado | 882 | |
| Tornado+nginx | 862 | |
| Web.py+CheryPy | 169 | |
| Web.py+nginx | 114 | |
GOMAXPROCS=2, 两个 Python 并发进程：
| 框架 | 请求速率 [1/sec] | |
|---|---|---|
| Go http | 1768 | |
| Twister | 1746 | |
| Tornado | 1682 | |
| Web.go | 1516 | |
| Tornado+nginx | 1378 | |
| Web.py+CheryPy | 308 | |
| Web.py+nginx | 198 | |
GOMAXPROCS=4, 四个 Python 并发进程：
| 框架 | 请求速率 [1/sec] | |
|---|---|---|
| Go http | 2063 | |
| Twister | 2020 | |
| Web.go | 1753 | |
| Tornado | 1662 | |
| Tornado+nginx | 1364 | |
| Web.py+CheryPy | 304 | |
| Web.py+nginx | 211 | |
Web.py+nginx 工作的 flup FastCGI 选项：multiplexed=False, multithreaded=False。如果 multiplexed=True 它会运行得慢一些。如果 multithreaded=True 而只有一个进程服务于 nginx 服务器，会报下面的错误：
[error] 18166#0: *66139 connect() to unix:/home/michal/Programowanie/web_bench/socket failed (11: Resource temporarily unavailable) while connecting to upstream
FastCGI 的多进程由 spawn-fcgi 产生。
结论
你可以看到 Go 赢得了几乎所有的测试用例。web.go 框架的那个不太理想的结果可能是由于它先尝试用指定的 URL 寻找静态页面，然后才会执行处理方法。让我惊讶的是 tornado Python 框架如此之高的性能，尤其是跟 web.py 框架相比而言。我同样对 CherryPy 服务器比 nginx+flup 快感到惊讶 (我使用 web.py+flup+nginx 跑几乎所有的 Python Web 应用)。
Leave a Reply