继续小测python web server
程序员文章站
2022-06-20 18:20:28
前两天参加了pycon2012上海站。虽然今年的pycon被各种吐槽,但还是有点收获的。比如shellxu的元,赖总的state/message,沈大侠谈的pypy等。
回来就想...
前两天参加了pycon2012上海站。虽然今年的pycon被各种吐槽,但还是有点收获的。比如shellxu的元,赖总的state/message,沈大侠谈的pypy等。
回来就想测一下用pypy跑web应用看看性能如何。顺便也对上次的测试范围作了点扩大化。
pycon上谈到的pyramid我虽然没用过,但是前身pylons和turbogears我是用过的,只是现在对这种重量级的东西兴趣不大。
轻量级的框架除了上次测试用到的web.py以外,bottle和flask也是很热的东西,尤其是flask,但是因为它对werkzeug的依赖令我不是很喜欢——我不喜欢名字不好念的东西,除了werkzeug以外还有像django这种。
不过这次还是都拿来测了。软硬件环境与上次测试相同。测试代码功能都是 your ip。bottle和flask的测试代码由令狐虫(https://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时需要作为一个注意事项加以考虑。
回来就想测一下用pypy跑web应用看看性能如何。顺便也对上次的测试范围作了点扩大化。
pycon上谈到的pyramid我虽然没用过,但是前身pylons和turbogears我是用过的,只是现在对这种重量级的东西兴趣不大。
轻量级的框架除了上次测试用到的web.py以外,bottle和flask也是很热的东西,尤其是flask,但是因为它对werkzeug的依赖令我不是很喜欢——我不喜欢名字不好念的东西,除了werkzeug以外还有像django这种。
不过这次还是都拿来测了。软硬件环境与上次测试相同。测试代码功能都是 your ip。bottle和flask的测试代码由令狐虫(https://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时需要作为一个注意事项加以考虑。