On Oct 6, 4:16 pm, "ihomest...@gmail.com" <ihomest...@gmail.com>
wrote:
> I read this doc about the performance comparison between Tornado and
> Django:http://www.tornadoweb.org/documentation
>
> I am quite new to both django and tornado (just heard about it). To me
> there are a few confusing points about the conclusion that "Tornado
> consistently had 4X the throughput of the next fastest framework, and
> even a single standalone Tornado frontend got 33% more throughput even
> though it only used one of the four cores" Maybe the document could
> add more comments about how the experiment is setup.
>
> The context of this statement is that Tornado runs with 4 frontends on
> a 4 core machine. My question is "Could django apps take advantage of
> 4 cores?" Is the 4X performance difference due to the setup or is it
> due to the reason that Tornado could make a better use of a 4 core
> machine?
>
> Any thoughts?
Like so many before them they chose benchmarks results which cast
their product/project in a good light. Reality is that it wasn't a
fair comparison.
The proper comparison would have been to demonstrate a simple WSGI
hello world application on both Tornado and Apache/mod_wsgi. If a WSGI
application on Tornado is too hard for them, sure they can stick with
their own hello world application. Point is though, they should not
have been comparing their hello world on their base level
infrastructure to something where a heavy weight framework is used.
Alternatively they should have demonstrated Django running on both,
although I don't know I would trust them to be able to configure
Apache/mod_wsgi properly so it runs to its best and to eliminate
application loading issues. At least with a WSGI hello world they
couldn't have done too much wrong.
FWIW, on MacOS X, if you run Tornado with their hello world
application and compare it with a hello world WSGI application running
on Apache/mod_wsgi and run a straight sequential request test to gauge
base performance overheads, then Apache/mod_wsgi performs up to 20%
better than Tornado. Granted that on MacOS X Tornado may not be using
epoll(), but I wouldn't see it making that much difference.
Overall it is just a big pissing contest anyway. The base level web
server infrastructure is not where the performance bottlenecks are. It
is going to be the application logic and more specifically database
interaction.
Just because the underlying web server use an asynchronous model will
not somehow magically make a real world blocking web application
somehow magically run 4 times quicker.
So, one could use the old phrase, lies, lies and benchmarks
(statistics). Problem is there slanted benchmarks have been propagated
around the place by people who know no better and they even stuck them
on Wikipedia as well. It will be impossible to get rid of it now or
balance the argument.
As final point, I would just say you use whatever you feel comfortable
with and which you find easy to manage and configure. That is more
important ultimately in production environments. If however it makes
you feel good to think what you are using the fastest web server
available, then by all means use web servers that want to claim that
as well.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
