Re: django vs tornado
Graham Dumpleton
On Mar 4, 9:08 am, gvkalra <gvka...@gmail.com> wrote:
> hi .... i have a presentation to make on django, wherein I have
> decided to include a section on Tornado .... I wish to show
> performance comparisons between django and tornado ..... how do I set
> up the scenario ?? ..... what I intend to achieve is this graph:http://wiki.developers.facebook.com/images/e/e8/Chart.png.... Please
> help me out
You do understand that those original Tornado benchmarks are to a
degree bogus as far as they were being used to compare Tornado to
Apache/mod_wsgi?
If you do a legitimate comparison and compare their basic Tornado
hello world program to a basic WSGI hello world program then Tornado
doesn't come out looking so good. On MacOS X, Tornado actually
performs worse than Apache/mod_wsgi for a basic hello world in each
system.
In other words, they should not have been comparing the performance
based on running a heavy weight Python framework like Django on top of
Apache/mod_wsgi to a native hello world program in Tornado.
A more realistic and fair comparison would be to compare Django
running on top of Tornado to Django running on top of Apache/mod_wsgi.
One of the things you will find from that is that any benefits from
Tornado being asynchronous get thrown out the window as to run a WSGI
application such as Django on top of Tornado you need to implement a
pool of blocking threads on top and as soon as you do that, the
overall performance of Tornado will drop.
That this occurs is because once you get a blocking WSGI model in
play, the bottleneck is usually never going to be the underlying
hosting mechanism and instead the bottleneck is your application and
database access.
So, what are you trying to show?
Are you wanting to show that a blocking Django or WSGI application
running on Tornado is faster? If you are, then you will have trouble
doing that.
If instead you want to show that the asynchronous model of web
programming gives you an advantage for your specific application, then
why use Django in the comparison at all. In that case it would be more
realistic to compare custom low level WSGI applications to a custom
low level Tornado specific application.
Help us to understand what result you want, whether that be positive
to Tornado or Apache/mod_wsgi, or somehow show the benefits of Django
for web programming, then there is no doubt a way of slanting the
results to get what you want.
Graham
Kenneth Gonsalves
> On Mar 4, 9:08 am, gvkalra <gvka...@gmail.com> wrote:
> > hi .... i have a presentation to make on django, wherein I have
> > decided to include a section on Tornado .... I wish to show
> > performance comparisons between django and tornado ..... how do I set
> > up the scenario ?? ..... what I intend to achieve is this
> > graph:http://wiki.developers.facebook.com/images/e/e8/Chart.png....
> > Please help me out
>
> You do understand that those original Tornado benchmarks are to a
> degree bogus as far as they were being used to compare Tornado to
> Apache/mod_wsgi?
>
as a person who has used django on tornado in production for some months, I
would like to mention two things:
1. tornado cannot handle urls with spaces in them - for example:
http://mysite.com/go here/ would be returned as http://mysite.com/go%20here/
which confuses the database
2. tornado goes haywire when confronted with {% csrf_token %}, giving
unpredictable errors.
I have stopped using it and till I can get something else up am using nginx
proxied to runserver - which is faster than tornado and handles the latest
django svn ok.
--
regards
Kenneth Gonsalves
Senior Associate
NRC-FOSS
http://certificate.nrcfoss.au-kbc.org.in
Continuation
> I have stopped using it and till I can get something else up am using nginx
> proxied to runserver - which is faster than tornado and handles the latest
> django svn ok.
> --
You are running the Django development server in production? Why? Why
not apache/mod_wsgi?
Kenneth Gonsalves
this is in a small vps with limited RAM. I found apache/mod_wsgi too slow and
bloated, so rather than spend time tuning apache, I shifted to nginx+tornado
which was fast and did not eat up RAM. Then I needed to do an svn up to get
some nifty new features and tornado could not handle the csrf stuff. So as a
purely temporary measure, I substituted runserver for tornado - intending to
just keep the clients happy until I could test and set up nginx+fcgi. But it
is working fine - with the added advantage of not needing to restart anything
on code changes. Of course I intend to change this, but have some deadlines to
meet first.
Rolando Espinoza La Fuente
[...]
>
> I have stopped using it and till I can get something else up am using nginx
> proxied to runserver - which is faster than tornado and handles the latest
> django svn ok.
Could you explain more about the csrf_token issue?
I'm testing django on tornado and didn't find any issue using the
admin interface
which uses csrf_token. I'm using latest django from svn and latest
tornado from git.
You can check the source that I'm using here:
http://github.com/darkrho/django-on-tornado
Regards,
Rolando
Kenneth Gonsalves
> > I have stopped using it and till I can get something else up am using
> > nginx proxied to runserver - which is faster than tornado and handles the
> > latest django svn ok.
>
> Could you explain more about the csrf_token issue?
>
> I'm testing django on tornado and didn't find any issue using the
> admin interface
> which uses csrf_token. I'm using latest django from svn and latest
> tornado from git.
>
I last used the latest django and tornado about a month back. I cannot explain
more than say that I got randomn errors with the csrf_token stuff. Both in
admin and outside admin, it would work at times and not work at times. And
each time with a different csrf_token error. If I have time today, I will try
again and report back.
Kenneth Gonsalves
> > I'm testing django on tornado and didn't find any issue using the
> > admin interface
> > which uses csrf_token. I'm using latest django from svn and latest
> > tornado from git.
> >
>
> I last used the latest django and tornado about a month back. I cannot
> explain more than say that I got randomn errors with the csrf_token
> stuff. Both in admin and outside admin, it would work at times and not
> work at times. And each time with a different csrf_token error. If I have
> time today, I will try again and report back.
>
I tried it with just a simple model and two views - works fine. Also tried it
with two simple sites and opened 4 tabs, two each for admin and two each for
the site - works. But in none of the more complex sites does it work.