Two Pythonweb frameworks: Django & amp; Tornado comparison

Two Pythonweb frameworks: Django & amp; Tornado are the most popular web frameworks in various language platforms; the reason for conjecture should be that the framework in py is very simple and the wheel is constantly invented.

Here we will describe the two py web frameworks I have learned for your reference and hope they can play a role in other aspects.

Django

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

Django is in a big and comprehensive direction. it is most famous for its fully automated management background: it only needs to use ORM for simple object definition, it can automatically generate the database structure and the full-featured Management backend.

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

Applications must use Django's built-in ORM. Otherwise, they will not be able to enjoy the various ORM-based conveniences provided by the framework. In theory, they can switch out their ORM modules, but this is equivalent to the demolition and re-decoration of the renovated house. it is better to go to the hair embryo room for a new decoration from the very beginning.

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

This experience can be referred to: http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus

Ruby Rails has similar problems. Twitter, for example, is the size of Twitter today. do not say Rails, or even Ruby, should be abandoned.

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

The quick launch product 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. It should also be the most influential and controversial part in its framework.

The design philosophy of Django templates is to completely separate code and styles. asp.net advocates code/templates separation, but it can still be technically mixed; django fundamentally eliminates the possibility of encoding and processing data in the template.

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

<%

Int I;

For (I = 0; I <10; I ++ ){

....

}

%>

Django does not support embedding code similar to the above. it can only use built-in functions of its template. In fact, it constructs a "new language" for its template "; because the new language is very simple, it can also be transplanted to different platforms.

In most cases, Django's template functions are sufficient, but for special cases (sometimes "special" is not very special), you still need to embed code in the template, then, you need to scale the template according to the rules of the template system. Sometimes, if you directly write a line of code in the template to solve the problem, after you use the template extension implementation, it will become more than a dozen lines of code.

Whether to tolerate programming in templates is the biggest controversy among Django templates.

Tornado

Tornado (http://www.tornadoweb.org) is Facebook's open-source framework, and its philosophy is almost two extremes with Django.

Tornado follows a few but refined directions. It also provides the template function. although not encouraged, the author can allow a small amount of encoding in the template (directly embed a single line of py code.

If Tornado is similar to asp.net, it only implements AsyncHttpHandler. In addition, all of them need to be implemented by themselves.

Well, in fact, it has templates, international support, and even the built-in OAuth/OpenID module to facilitate third-party login. In fact, it also directly implements the Http server.

However, it does not have an ORM (only a simple mysql package) or even no Session support, let alone an automated background like Django.

Suppose it is a large website. with high performance requirements, each part of the framework often needs to be customized, and there are very few modules that can be reused. a website developed with Django, after continuous customization, the rest of the Django framework is likely to be what tornado can provide at the beginning.

The same way.

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

Tornado directly embeds the HTTP server in order to efficiently implement Comet/backend Asynchronous call to the HTTP interface.

The front-end does not require apache, lighttpd, or nginx to be accessed by browsers. However, it does not fully implement the HTTP 1.1 protocol, therefore, the official documentation recommends that you use nginx at the front end in the production environment, and reverse proxy at the back end to multiple Tornado instances.

Tornado itself is a single-threaded asynchronous network program. by default, it runs multiple instances based on the number of CPUs at startup, taking full advantage of multiple CPU cores.

===== Single-thread asynchronous ====

The website basically has database operations, while Tornado is single-threaded, which means that if the database query returns too slowly, the response of the entire server will be blocked.

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

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

A system must meet high traffic requirements. it must solve the database query speed problem!

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

Asynchronization and ** no ** essentially refer to the system performance. it only avoids redundant network response waits and switches the CPU consumption of threads.

If the database query response is too slow, you need to solve the database performance problem, rather than calling the front-end Web application of the database.

For queries of data returned in real time, it is ideal to ensure that all data is in the memory, and the database hard disk IO should be 0; such queries can be fast enough; and if the database query is fast enough, therefore, front-end web applications do not need to encapsulate data queries as asynchronous.

Even with coroutine, asynchronous programs always increase the complexity of synchronization programs. it is worth measuring whether these extra complexities are handled.

If the backend query is too slow to bypass, we recommend that you encapsulate the query in the backend as an HTTP interface and then use the asynchronous HTTP client built in Tornado for calling.