Two Python web frames: Django & Tornado comparison

Python's web framework is probably the most popular in a variety of language platforms, and the reason for this is that it is simple to construct a framework in Py, making the wheel constantly invented.

Here is a description of the two PY web framework I have learned, for your reference, hoping to play the role of his mountain stone.

Django

Django should be the most well-known PY framework, and Google App engine and even Erlang have frames affected by it.

Django is the direction of chatty, its most famous is its fully automated management background: Just use the ORM, do simple object definition, it can automatically generate database structure, and full-featured management background.

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

The application must use the Django built-in ORM, otherwise it will not be able to enjoy the various facilities provided in the framework based on its ORM, can theoretically be cut to replace its ORM module, but this is equivalent to the completion of the demolition of the house renovated, rather than the beginning of the hair embryo room to do a new decoration.

Django's selling point is the ultra-high development efficiency, its limited performance, the use of Django projects, after the traffic reaches a certain scale, it needs to be reconstructed to meet the performance requirements.

This experience can be consulted: Http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus

There's a similar problem with Ruby's rails, and Twitter, for example, pushes it to the scale of today, not to mention rails or even Ruby.

It's my feeling. Django applies to small and medium-sized websites, or as a tool to quickly prototype a product as a large website.

Quick Launch product is kingly:

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

===== Django Template =====

Django's templating system design is interesting and should be the most influential and controversial part within its framework.

The design philosophy of the Django template is to completely separate the code from the style, and the ASP. NET advocates separating the code/template, but technically it can be mixed, and Django is fundamentally eliminating the possibility of coding and processing data in the template.

For example, the ASP. NET template can be written in:

<%

int i;

for (i==0;i<10;i++) {

....

}

%>

Django is completely unsupported by embedding code similar to the above, only can use its template built-in functions, which in fact is a "new language" for its template, and because this "new language" is very simple, it is also able to migrate its templates to different platforms.

In most cases, Django's template functionality is sufficient, but for special (sometimes "special" and not very special) situations, or to embed code in a template, you need to make template extensions based on the rules of their template system. Sometimes, the template directly write a line of code to solve the problem, with the template extension implementation, will become more than 10 lines of code.

Whether to tolerate programming in templates is the most controversial of the Django template.

Tornado

Tornado (http://www.tornadoweb.org) is a framework for Facebook's open source, with a philosophy that is nearly two extreme with Django.

Tornado Go is the direction of few but good, it also provides template functionality, although discouraged, but the author is allowed to be in the template for a small number of encodings (directly embedded single-line py code).

If the tornado is somewhat similar to the Asynchttphandler in comparison with ASP.

Well, in fact, it has a template, has international support, and even has built-in Oauth/openid module, easy to do third-party login, it actually also directly implemented the HTTP server.

But it does not have an ORM (only a super-simple package for MySQL), not even the session support, not to mention the automated backend like Django.

Suppose is a large website, under the requirements of high performance, the various parts of the framework often need to be customized, the module can be reused very little; a Django-developed web site, the parts are constantly customized, and the Django framework is the rest of the tornado, which is likely to be provided at the outset.

Same direction

===== HTTP Server =====

In order to efficiently implement the comet/backend asynchronous call HTTP interface, Tornado is directly embedded in the HTTP server.

The front end does not need to add apache/lighttpd/nginx and so on can be accessed by the browser, but it does not fully implement the HTTP 1.1 protocol, so the official document is recommended users in the production environment in the front-end use Nginx, back-end reverse proxy to multiple tornado instances.

Tornado itself is a single-threaded asynchronous network program that, when started by default, runs multiple instances based on the number of CPUs, leveraging the benefits of CPU multicore.

===== single-thread asynchronous =====

The site basically has database operations, and Tornado is single-threaded, which means that if the database query returns too slowly, the entire server response is blocked.

Database queries are, in essence, remote network calls; Ideally, these operations are also encapsulated as asynchronous, but Tornado does not provide any support for this and * * *.

This is Tornado's * * * design, not a flaw.

A system, to meet high traffic, it is necessary to solve the problem of database query speed!

Database if there is query performance problem, the whole system is optimized anyway, the database will be the bottleneck, slow down the whole system!

Async and * * cannot essentially refer to the performance of the system; it simply avoids redundant network response waits and switches the CPU consumption of the thread.

If the database query response is too slow, you need to address the performance issues of the database, rather than the front-end Web app that calls the database.

For data queries that are returned in real time, it is desirable to ensure that all data is in memory, that the database hard-disk IO should be 0, that the query is fast enough, and that if the database query is fast enough, the front-end Web application has no need to encapsulate the data query as asynchronous.

Even with the use of a coprocessor, asynchronous programs always increase complexity for the Synchronizer, and it is worth measuring whether it is worthwhile to deal with these additional complexities.

If the backend has queries that are too slow to bypass, Tornaod's recommendation is to encapsulate these queries in a back-end wrapper as an HTTP interface, and then invoke them using the tornado built-in asynchronous HTTP client.

