Go 和 Python Web 服务器性能对比
在工作过程中发现,我需要比 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 应用)。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。