Two Python web frameworks: Django & Tornado comparison

Among various language platforms, python probably has the most web frameworks emerging; I guess the reason is that it is very simple to construct frameworks in py, so the wheel is constantly being invented.

Here I will describe the two py web frameworks that I have learned about for your reference. I hope they can serve as a reference for others.

Django

Django should be the most famous py framework. Google App Engine and even Erlang have frameworks affected by it.

Django is taking a large and comprehensive direction. It is most famous for its fully automated management backend: you only need to use ORM and make simple object definitions, and it can automatically generate database structures and full-featured databases. Management background.

The convenience provided by Django also means that Django’s built-in ORM is highly coupled with other modules in the framework.

The application must use Django’s built-in ORM, otherwise you will not be able to enjoy the various ORM-based conveniences provided in the framework; in theory, you can switch out its ORM module, but this is equivalent to renovating a decorated house To dismantle and renovate, it is better to go to the rough room to do a new decoration from the beginning.

Django’s selling point is its ultra-high development efficiency, but its performance expansion is limited; projects using Django need to be restructured after the traffic reaches a certain scale to meet performance requirements.

For experience in this area, you can refer to: http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus

Ruby’s Rails also has similar problems; take Twitter as an example, push At today's scale, not to mention Rails, even Ruby needs to be abandoned and started over.

In my opinion, Django is suitable for small and medium-sized websites, or as a tool for large websites to quickly implement product prototypes.

Launching products quickly is king:

Believe it or not, the bigger problem isn't scaling, it's getting to the point where you have to scale. Without the first problem you won't have the second. - http://gettingreal.37signals.com/ch04_Scale_Later.php

===== Django template=====

Django’s template system design is very interesting, and it should also be the most influential and controversial within its framework part.

The design philosophy of Django templates is to completely separate code and styles; asp.net advocates the separation of code/templates, but technically they can still be mixed; while Django fundamentally eliminates coding and styling in templates. Possibility of processing data.

For example, in the asp.net template you can write:

int i;

for(i==0;i

....

}

%>

Django does not support embedding code like the above at all, and can only use the functions built into its templates; this actually constructs a "new language" for its templates; due to this "new Language" is very simple, so its templates can be ported to different platforms.

In most cases, Django's template function is sufficient, but for special (sometimes "special" is not very special) situations, you still need to embed code in the template, then you need to according to its template system Rules do template expansion. Sometimes, a problem that can be solved by writing one line of code directly in the template will become more than a dozen lines of code after being implemented with template extension.

Whether programming in templates is tolerated is the most controversial aspect of Django templates.

Tornado

Tornado ( http://www.tornadoweb.org ) is an open source framework from Facebook. Its philosophy is almost the opposite of Django.

Tornado is taking the direction of less but more precise. It also provides template function; although it is not encouraged, the author can allow a small amount of coding in the template (directly embed a single line of py code).

If compared with asp.net, Tornado is a bit similar and only implements AsyncHttpHandler; apart from that, you need to implement everything yourself.

Well, in fact, it has templates, international support, and even a built-in OAuth/OpenID module to facilitate third-party login. It actually directly implements the HTTP server.

But it doesn’t have an ORM (only a super simple package of mysql), and it doesn’t even have Session support, let alone an automated backend like Django.

Assume it is a large website. Under the requirement of high performance, each part of the framework often needs to be customized, and there are very few modules that can be reused; for a website developed with Django, each part has been continuously customized, and Django The rest of the framework is most likely what tornado can provide at the beginning.

Different paths lead to the same destination.

====== HTTP server =====

Tornado directly embeds the HTTP server in order to efficiently implement Comet/backend asynchronous calling of the HTTP interface.

The front-end can be accessed by the browser without adding apache/lighttpd/nginx, etc.; but it does not fully implement the HTTP 1.1 protocol, so the official document recommends users to use nginx on the front-end in a production environment, and the back-end will Proxy to multiple Tornado instances.

Tornado itself is a single-threaded asynchronous network program. When it is started by default, it will run multiple instances according to the number of CPUs; taking full advantage of the multi-core CPU.

====== Single-threaded asynchronous =====

Websites basically have database operations, and Tornado is single-threaded, which means that if the database query returns too slowly, the entire server response will be blocked.

Database queries are essentially remote network calls; ideally, these operations would be encapsulated as asynchronous; but Tornado does not provide any support for this.

This is a **design** of the Tornado, not a flaw.

For a system to meet high traffic, it must solve the problem of database query speed!

If there is a query performance problem in the database, no matter how optimized the entire system is, the database will be a bottleneck and slow down the entire system!

Asynchronous does not **essentially** improve the performance of the system; it just avoids unnecessary waiting for network responses and the CPU consumption of switching threads.

If the database query response is too slow, what needs to be solved is the performance problem of the database; not the front-end web application that calls the database.

For real-time returned data query, ideally it is necessary to ensure that all data is in memory, and the database hard disk IO should be 0; only such query can be fast enough; and if the database query is fast enough, then the front-end web application will also There is no need to encapsulate data queries as asynchronous.

Even if you use coroutines, asynchronous programs will always increase the complexity of synchronous programs; what needs to be measured is whether dealing with the additional complexity is worth it.

If there are queries on the backend that are too slow to bypass, Tornaod’s suggestion is to encapsulate these queries independently in the backend into HTTP interfaces, and then use Tornado’s built-in asynchronous HTTP client to make calls.