写在前面:
本文的数据涉及到我面试时遇到过的问题,大概一次 http 请求到收到响应需要多少时间。这个问题在实际工作中与框架有比较大的关系,因此特别就框架的性能做了一次分析。
这里使用 2016 年 6 月 9 日的报告数据: Python's Web Framework Benchmarks。本文仅关注目前最常用的三大 Python 框架:Django、 Flask 以及 Tornado。
报告主要比较三点:
- JSON:序列化一个对象,并返回一个 json。
- 远程性能:从远程服务器上返回 http response 的时间
- 数据库性能:使用 ORM(对象关系映射)从数据库获取数据,并渲染到模板上的时间
最基本的 json 测试:Django 与 Flask 占优
单纯在本地测试 json 的序列化,Django 完成一次 json 序列化的平均时间 42.52 毫秒,每秒请求量 4762 次。Flask 在此项测试中,与 Django 的比较不相上下,Flask 平均时间 43.33 毫秒,每秒请求量 4630 次。Tornado 完成 json 序列化的平均时间高达 77.51 毫秒,是所有框架中耗时最长的,每秒请求数是 2578 次,也是低于 Django 与 Flask 的水准。这仅仅说明框架在本地处理 json 的速度。框架还涉及 http request/response 以及数据库的读写,后面还需要综合来分析框架的性能。
处理远程 http 请求的能力:Tornado 占绝对优势
从这项测试开始,Tornado 的强悍开始显现。Tornado 完成 http 请求的平均时间是 1.04 秒,而 Flask 是 3.34 秒,Django 是 3.48 秒,http 响应速度 Tornado 比 Flask 以及 Django 快三倍。
值得注意是,如果综合考虑 http 相应速度以及json 处理速度,如果把两项指标的平均时间相加:Tornado 耗时 1114.48 毫秒,Flask 是 3387.60 毫秒,Django 是 3519.88 毫秒。
Tornado 的好成绩得益于其自带的异步特性,而 Django 与 Flask 是同步框架,在处理请求时性能受限。但是实际使用中,一般是 Django/Flask + Celery + Redis/Memchaned/RabbitMQ 的模式,由此带上了异步处理的能力。
数据库与模板处理性能:Tornado 与 Flask 旗鼓相当
Django 饱受诟病的地方就是 Django ORM 确实很慢,加上模板处理时间,Django 的平均时间 2904.04 毫秒,每秒处理请求量 42.9 次。然而 Django 的大部分功能是建立在其 Django ORM 基础上,比如 models, admin, forms 甚至第三方框架 django-rest-framework。Django 的开发效率与维护非常棒,然而 Django ORM 深度绑定了该框架,如果你需要把 Django ORM 换成其它轮子,那么也意味着 Django 的诸多优秀特性将从此告别。
Flask 事实上的 ORM 是 SQLAlchemy,根据董伟明的估计,SQLAlchemy 比 MySQLdb 的耗时多 5% 左右,所以是性能相当不错的数据库 ORM。得益于 SQLAlchemy 的优异性能,Flask 的每秒处理请求数为 123 次,平均处理时间 1440.24 秒,与 Tornado 性能相当。
Tornado 的每秒处理请求数为 143 次,平均处理时间 1344.69 秒。对于数据库与模板的处理,Tornado 与 Flask 不相上下。
结论
- Django:Python 界最全能的 web 开发框架,battery-include 各种功能完备,可维护性和开发速度一级棒。常有人说 Django 慢,其实主要慢在 Django ORM 与数据库的交互上,所以是否选用 Django,取决于项目对数据库交互的要求以及各种优化。而对于 Django 的同步特性导致吞吐量小的问题,其实可以通过 Celery 等解决,倒不是一个根本问题。Django 的项目代表:Instagram,Guardian。
- Tornado:天生异步,性能强悍是 Tornado 的名片,然而 Tornado 相比 Django 是较为原始的框架,诸多内容需要自己去处理。当然,随着项目越来越大,框架能够提供的功能占比越来越小,更多的内容需要团队自己去实现,而大项目往往需要性能的保证,这时候 Tornado 就是比较好的选择。Tornado项目代表:知乎。
- Flask:微框架的典范,号称 Python 代码写得最好的项目之一。Flask 的灵活性,也是双刃剑:能用好 Flask 的,可以做成 Pinterest,用不好就是灾难(显然对任何框架都是这样)。Flask 虽然是微框架,但是也可以做成规模化的 Flask。加上 Flask 可以自由选择自己的数据库交互组件(通常是 Flask-SQLAlchemy),而且加上 celery +redis 等异步特性以后,Flask 的性能相对 Tornado 也不逞多让,也许Flask 的灵活性可能是某些团队更需要的。
总结,萝卜白菜各有所爱,然而机器的效率(程序的性能)与程序员的效率(可维护性、开发速度)是一对矛盾。选择什么样的架构组合,取决于产品的特性以及团队的能力。