首页 > 代码库 > 小测几种python web server的性能

小测几种python web server的性能

2024-07-13 20:40:07   220人阅读

http://blog.csdn.net/raptor/article/details/8038476

因为换了nginx就不再使用mod_wsgi来跑web.py应用了，现在用的是gevent-wsgi，效果还不错。但还是想试试别的，比如传说中超级猛的meinheld什么的。

软硬件环境

硬件：

一台04年初购置的IBM X235服务器，CPU为Xeon 2.4G两颗，内存1G，100M网卡。

软件：

Ubuntu Server 10.04 LTS
Apache 2.2.14
Nginx 0.7.65
Python 2.6.5
web.py 0.37
mako 0.7.2
sqlalchemy 0.7.8
gevent 0.13.7
gunicorn 0.14.6
meinheld 0.4.15

测试代码

有五个版本，分别是：

最基本的WSGI helloworld

[python] view plaincopy
 
  1. def application(environ, start_response):  
  2.     status = ‘200 OK‘  
  3.     resp = "Hello world!"  
  4.     resp_headers = [(‘Content-type‘,‘text/plain;charset=utf-8‘)]  
  5.     start_response(status, resp_headers)  
  6.     return [resp]  

最基本的web.py your IP

[python] view plaincopy
 
  1. class yourip:  
  2.     def GET(self):  
  3.         return "Your IP is : %s" % web.ctx.ip  

加了mako模板的web.py

[python] view plaincopy
 
  1. class onlymako(BaseHandler):  
  2.     @expose("yourip")  
  3.     def GET(self):  
  4.         return dict(yourip=web.ctx.ip)  

加了数据库的web.py

[python] view plaincopy
 
  1. class onlydb:  
  2.     def GET(self):  
  3.         created = web.ctx.provider.once_access(web.ctx.ip)  
  4.         return "You have logged : %s" % created  

和同时加了数据库和mako模板的web.py —— 这也是最接近实际应用的情况

[python] view plaincopy
 
  1. class makodb(BaseHandler):  
  2.     @expose("index")  
  3.     def GET(self):  
  4.         created = web.ctx.provider.once_access(web.ctx.ip)  
  5.         return dict(created=created)  

测试目标

五种运行环境：

web.py的测试环境app.run
web.py+gevent-WSGI
gunicorn默认（sync）
gunicorn+gevent
gunicorn+meinheld

gunicorn使用 -w 4 参数，经实际比较过，这个参数并不能有效增加rps，但在高并发测试情况下可以在一定程度上减少失败率。

测试方式

ApacheBench 2.3(Ubuntu Desktop 12.04)

RPS测试参数为 -n 200 -c 22 测五次取rps平均值。

之所以用这样比较小的参数，是因为再高了，其中某些测试就通不过了。

测试结果

RPS测试WSGI helloworldWeb.py YourIPWeb.py+MakoWeb.py
+SQLAlchemy
(SQLite)		Web.py+Mako
+SQLAlchemy
(SQLite)

Web.py
+SQLAlchemy
(Postgresql)

Web.py+Mako
+SQLAlchemy
(Postgresql)
Web.py app.run无1309375*45*5940
web.py+gevent无42213082547453
gunicorn default85443913693669062
gunicorn+gevent69529111574567856
gunicorn+meinheld356568216084659864

其中加了“＊”的数字发生了数据库错误，仅供参考。

另外，用同样的参数测了一下Apache2处理静态文件的rps为：1780，nginx为：2951。

＝＝＝附加的分割线＝＝＝

再附加一个在我的Atom小服务器上的部分测试结果：

Nginx处理静态文件的rps为：4000左右。

WSGI hello world测试：gunicorn+meinheld约为：3800。gunicorn+gevent约为：1100。gunicorn default约为：1400。

your IP测试：gunicorn+meinheld约为：1000。gunicorn+gevent约为：450。gunicorn default约为：700。

相比之下这个Atom小机器比IBM服务器猛好多。硬件发展速度真是太快了。

附软硬件环境：

Atom D525 1.6G双核，2GRAM，FreeBSD 9，Nginx 1.2.2，Python 2.7.3，其它同IBM服务器。

并且在这个Atom机器上 -w 参数对rps有明显贡献…看来是因为老服务器的问题才效果不明显，只是不确定是硬件问题还是OS问题。

结论

meinheld的确猛，处理最简单的WSGI比Apache2处理静态文件还要猛一倍，跟Nginx相当甚至更强。

app.run的rps比预想的要好很多，只是并发数真不行，-c 参数略加大就会出现大量失败测试。

gevent已经足够好了，不过居然比gunicorn的sync模式还慢真是有点不科学啊。

gunicorn的好处在于管理方便，并且可以灵活使用各种work_class，特别奇怪的一点是居然sync模式也这么快。

web.py的性能影响还是很明显的。

模板的影响也很明显——mako已经算是很快的模板了，真不知道用那些KID之类很慢的模板会是什么效果。

数据库的影响更大，不过pgsql的性能居然能跟sqlite差不多，真不知道是sqlite太慢还是pgsql太快…

本来前一阵我刚听说OpenResty这货的时候还是很有兴趣的，但是现在看到meinheld的表现以后，觉得还是算了吧，毕竟用OpenResty还要去学Lua…现在要学的东西太多，能用Python搞定的事情就不去麻烦Lua了。

 

 

上次的测试见《小测几种python web server的性能》。

前两天参加了PyCon2012上海站。虽然今年的PyCon被各种吐槽，但还是有点收获的。比如ShellXu的元编程，赖总的state/message，沈大侠谈的pypy等。

回来就想测一下用pypy跑web应用看看性能如何。顺便也对上次的测试范围作了点扩大化。

PyCon上谈到的Pyramid我虽然没用过，但是前身Pylons和Turbogears我是用过的，只是现在对这种重量级的东西兴趣不大。

轻量级的框架除了上次测试用到的web.py以外，bottle和flask也是很热的东西，尤其是flask，但是因为它对Werkzeug的依赖令我不是很喜欢——我不喜欢名字不好念的东西，除了Werkzeug以外还有像Django这种。

不过这次还是都拿来测了。软硬件环境与上次测试相同。测试代码功能都是 your IP。bottle和flask的测试代码由令狐虫(http://ch-linghu.me/blog/)友情提供，特此鸣谢。

Server都是用的gunicorn default(sync)，单进程。没有特别精确统计，取近似平均值。

RPS测试WSGI helloworldWeb.py YourIPBottle Your IPFlask Your IP
python850440580400
pypy（＊）11008001000600

就这个结果来看，pypy的作用还是比较明显的。另外flask看上去也一般啊，虽然号称扩展能力强，不知道扩下去性能是不是会影响更大。但bottle的确是很不错的样子。

（＊）当然因为pypy是JIT方式运行的，所以有一个“预热”的过程。请求量过小的时候不但不会更快，反而会慢很多。基本上在“冷”状态下，pypy环境下的RPS只有python环境的一半不到。需要有连续大量请求之后才能达到“热”状态。上面的RPS数据都是“热”状态的结果。

达到“热”状态的过程也各不相同。标准WSGI在几百个请求之后即可达到，bottle大概需要一千多个请求，web.py需要将近一万个请求，而flask要超过一万。

另外，就测试的软硬件环境来说，gunicorn default(sync)单进程最高只能达到130个并发左右，4进程可以达到270个并发左右。因为换用不同的框架结果都是如此，当然标准WSGI会略高一些（单进程170左右），所以主要应该还是gunicorn决定。

换用gunicorn+gevent测试的话，所有框架上到单进程1000并发没问题，只是RPS会有相应下降而已。这个时候就体现出gevent相比sync的优势所在了——虽然低并发时sync速度比gevent还快，但是在高并发下，sync直接死掉（无响应直至超时），gevent只是速度慢了而已。

同样换用gunicorn+meinheld，最高并发也只能到260而已，只比sync模式高一倍，但还是远低于gevent。而且meinheld的表现比较奇怪，一开始还可以接受1000并发的，然后就越来越少。另外，它的表现也与gevent不同，gevent在高并发下是一开始就按比较低RPS工作，而meinheld则是仍然以高RPS工作，但到后面就会爆掉（客户端显示连接被服务端中断）。

经令狐分析，可能的原因是这样的：

sync从字面上理解应该是使用线程阻塞模式，所以在低并发下可以利用到服务器的多核，所以RPS比gevent要高。但是在高并发下，因为线程过多，导致线程切换成本过高失去响应。

meinheld应该也是使用了多线程（同时使用greenlet的协程），所以性能最好，但是在高并发下同样会面临与sync一样的多线程问题。

gevent则胜在轻量，虽然没有多线程利用多核的优势，但同样可以用多进程来利用，而且在高并发的时候，处理不了的请求是在排队中，所以不会爆掉或死掉，只是RPS下降而已。当然，在极端高并发的情况下，请求队列是有可能溢出的，但那已经是比sync/meinheld高得多得多的并发了。

不过之前对meinheld过于乐观的看法是需要改变了，因为在同样高并发的情况下，nginx毫无压力，虽然RPS下降不少，但仍然是远高于gevent，更不用说已经趴下的sync和meinheld……

最后，在测试中还发现了bottle的一个性能问题：404错误的响应比正常页面慢很多。令狐因此对测试程序作了改进，加了一个自定义404页面，这样404的响应就和正常页面差不多了。这一点在使用bottle时需要作为一个注意事项加以考虑。


联系
我们