The pros and cons of Django and Tornado
Django
advantage:
- Yamato Full (heavyweight framework)
- Comes with orm, template, view
- The functions you need can also find third-party apps
- Focus on efficient development
- Fully automated management background (only need to use ORM, make a simple definition, you can automatically generate database structure, full-featured management background)
- session function
shortcoming:
- template is not very easy to use (from its own shortcomings)
- It is inconvenient to use nosql for the database (from its own shortcomings)
- If there are not many functions, it is easy to be bloated
Tornado
advantage:
- Less is more (lightweight framework)
- Focus on superior performance and fast speed
- Solve high concurrency (request processing is a callback-based non-blocking call)
- Asynchronous non-blocking
- websockets long connection
- Embedded HTTP server
- A single-threaded asynchronous network program that runs multiple instances according to the number of CPUs at default startup; takes advantage of multiple CPU cores
- custom module
shortcoming:
- There are many third-party modules for the template and database parts to choose from, which is not conducive to encapsulation as a functional module
Summarize:
For performance, Tornado is the first choice; for development speed, both Django and Flask are fine. The difference is that Flask leaves many functions to third-party libraries to complete, so Flask is more flexible.
In summary:
Django is suitable for rapid development of beginners or small teams, suitable for management, blogging websites, or websites with very complex functions and many needs
Tornado is suitable for a high degree of customization, suitable for websites with high traffic and asynchronous situations
Django overview
Django is probably the most famous python framework, Google App Engine and even Erlang have frameworks influenced by it.Django is going in a big and comprehensive direction. It is most famous for its fully automated management background: just use ORM and make simple object definitions, and it can automatically generate the database structure and full-featured 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 it will not be able to enjoy all the conveniences provided by the framework based on its ORM; in theory, its ORM module can be switched, but this is equivalent to demolishing the renovated house and redecorating it. It is better to go to the embryo room to do a new decoration from the beginning.
The selling point of Django is its high development efficiency, and its performance expansion is limited; for projects using Django, after the traffic reaches a certain scale, it needs to be refactored to meet the performance requirements.
Ruby's Rails has a similar problem; take Twitter for example, Twitter has reached the scale it is today, not to mention Rails, even Ruby needs to be thrown out.
As far as I feel, Django is suitable for small and medium-sized websites, or as a tool for quickly realizing product prototypes for large-scale websites.
Tornado overview
Tornado is a framework open sourced by Facebook, and its philosophy is almost two extremes from Django. Tornado is an asynchronous framework. Tornado basically only has the C layer in MVC.Tornado takes the direction of being less and more refined, and it also provides template functions; although it is not encouraged, the author can allow a small amount of coding in the template.
If compared with asp.net, Tornado is a bit similar and only implements AsyncHttpHandler; other than that, all need to be implemented by yourself.
Well, in fact, it has templates, internationalization support, and even a built-in OAuth/OpenID module, which is convenient for third-party login. In fact, it also directly implements the Http server.
But it has no ORM (only a super simple package of mysql), not even Session support, not to mention the automated background like Django.
Assuming it is a large website, under the requirement of high performance, various parts of the framework often need to be customized, and there are very few modules that can be reused; a website developed with Django, each part is continuously customized, and the rest of the Django framework, Most likely that's what tornado has to offer in the first place.
Same way.
===== HTTP Server =====
In order to efficiently implement Comet/backend asynchronous calls to the HTTP interface, Tornado directly embeds the HTTP server.The front end can also be accessed by browsers without adding apache / lighttpd / nginx, etc.; but it does not fully implement the HTTP 1.1 protocol, so the official document recommends that users use nginx in the front end in the production environment, and the back end reverse proxy to multiple Tornado instance.
Tornado itself is a single-threaded asynchronous network program. When it starts up by default, it will run multiple instances according to the number of CPUs; it takes full advantage of the multi-core CPU.
===== Single Thread Async =====
The website basically has 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 are also encapsulated as asynchronous; but Tornado does not provide any support for this.
This is a "design" of Tornado, not a flaw.
A system, to meet high traffic; must solve the problem of database query speed!
If there is a query performance problem in the database, no matter how the entire system is optimized, the database will be the bottleneck and slow down the entire system!
Asynchrony doesn't inherently improve system performance; it just avoids redundant network response waits, and the CPU cost of switching threads.
If the database query response is too slow, the performance problem of the database needs to be solved; it is not the front-end Web application that calls the database.
For data query returned in real time, ideally, it is necessary to ensure that all data is in memory, and the database hard disk IO should be 0; such a query can be fast enough; and if the database query is fast enough, then the front-end web application will not query the data. Encapsulation as async is necessary.
Even with coroutines, asynchronous programs always add complexity to synchronous programs; the question is whether it is worth dealing with the extra complexity.
If there are queries in the backend that are too slow to bypass, Tornaod's suggestion is to encapsulate these queries in the backend independently into HTTP interfaces, and then use Tornado's built-in asynchronous HTTP client to call them.