继续小测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 helloworld Web.py YourIP Bottle Your IP Flask Your IP
python 850 440 580 400
pypy（＊） 1100 800 1000 600
就这个结果来看，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时需要作为一个注意事项加以考虑。

补充：Web开发 , Python ,