A brief analysis of several large frames of common python web

In a variety of language platforms, Python's emerging web framework is probably the most, a flourishing world, a variety of micro-framework, the framework of countless, guess the reason is that the framework in Python is very simple, so that the wheel is constantly invented. The

In the Python community there is always a topic about the merits of the Python framework. Here are some of Python's main frameworks:

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 within the framework based on its ORM, it can theoretically be replaced with its ORM module, but this is equivalent to the completion of the demolition of the house renovated, rather than the first to go to the hair embryo room to do

The 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.

The main drawback of Django is that Django insists on making all the wheels, the system is relatively closed, and Django's most reviled place is:

· The system is tightly coupled, if you feel that the Django built-in feature is not very good, want to use a favorite third-party library to replace is difficult, such as the following will be said Orm, Template. It's almost impossible to use SQLAlchemy or Mako in Django, even if you hit a

Some patches will also make you feel very, very uncomfortable.

· Django's own ORM is far less powerful than SQLAlchemy, except in the Django Acre, SQLAlchemy is the de facto ORM standard in the Python world, and other frameworks support SQLAlchemy, But Django still insists on its own set. Django's

The developer's support for SQLAlchemy was discussed and tried, but eventually it was abandoned, and it was estimated to be too expensive and difficult to fit with the other Django modules.

· Template function is weak, can not insert Python code, to write a more complex logic need to use Python to implement the tag or filter. 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 writes directly

A line of code can 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.

Pylons & TurboGears & REPOZE.BFG

In addition to Django, another big head is pylons, because turbogears2.x is based on pylons, and REPOZE.BFG has been incorporated into pylons project, TurboGears and REPOZE.BFG are no longer discussed separately.

The design philosophy of pylons and Django is completely different, the pylons itself has only about 2000 lines of Python code, but it also comes with some third-party modules that are almost pylons. Pylons only provides a shelf and optional options, you can according to your own preferences from

From the selection of template, ORM, form, auth and other components, the system is highly customizable. We often say that Python is a glue language (glue language), then we can say pylons is a glue language design glue framework.

Choose Pylons more is to choose its freedom, the choice of freedom is also indicative of your choice of nightmare:

· Learning nightmares, pylons relies on many third-party libraries, they are not pylons, you learn pylons at the same time you have to learn how to use these libraries, the key sometimes you do not know what you want to learn. Pylons's learning curve is much higher than Django, and the

The official documents of the former pylons have been the object of criticism, but the definitive guide to pylons the book, which has changed. For this reason, pylons was once hailed as a Python framework that was only suitable for use by a master.

· Debugging nightmare, because of the number of modules involved, once the error occurs, it is more difficult to locate the problem where. May be you write the program of the wrong, may be pylons error, or sqlalchemy error, do not formencode have a bug, anyway very ling

Mess up. This problem can only be solved by using it well.

· Upgrade nightmare, installation pylons large and small to install nearly 20 Python modules, each with their own version number, to upgrade the version of Pylons, which module is incompatible with the problem is possible, the upgrade is basically difficult. So far Reddit's pylons still stays in

On the 0.9.6 of antiques, SQLAlchemy is also the 0.5.3 version, which should be related to this article.

The convergence of pylons and REPOZE.BFG may lead to the next framework that challenges Django status.

Tornado & web.py

Tornado (http://www.tornadoweb.org) is a framework for Facebook's open source, with a philosophy that is nearly two extreme with Django. Tornado is a Web server (not detailed in this article), but also a class web.py micro-framework.

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 web site, in the high-performance requirements, the framework of the various parts of the need to be customized, the module can be reused very little; a Django-developed web site, the parts are constantly customized, the Django framework remains, most likely tornado a

At the beginning of this part that can be provided.

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.

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.

