Re: How to interpret the performance difference: Tornado vs Django
On Wednesday 07 Oct 2009 3:26:21 am ihomest...@gmail.com wrote: > Since many have mentioned that django is not an asynchronous > framework, you still have not understood. django is a framework. It is not a webserver, or any kind of server. (oops, just noticed that this discussion is on the devel list - please shift it to the users list) -- regards kg http://lawgon.livejournal.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How to interpret the performance difference: Tornado vs Django
Read: http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modwsgi.html Graham On Oct 7, 8:56 am, "ihomest...@gmail.com" wrote: > Thanks to you guys for the insightful discussions and thoughts on this > topic. It is always good to hear from many sides to get a complete > picture. I agree with your comments about the benchmark thing and that > is the also the origin of my confusions when I read the benchmark part > in the Tornado doc. > > Since many have mentioned that django is not an asynchronous > framework, this leads to one of my other question: would anyone shed > any thoughts on how to configure django to take advantage of multi > core machines? Or is there nothing extra we need to do and everything > is already taken care of by the underlying django framework on multi > cores? > > Thanks. > > On Oct 6, 3:23 am, Roberto De Ioris wrote: > > > > > On Mon, 2009-10-05 at 22:16 -0700, 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? > > > Thanks. > > > Once in a while, someone (me included with uwsgi) spit out a new > > outstanding deploy technology > > forgetting that 99.999% of bottlenecks are on the apps and not on > > the webservers. > > > Putting all the efforts on speed is now completely useless, all of this > > tecnology are heavily based on optimization done by the kernel (epoll, > > kqueue, sendfile, vector i/o, varouis aio technics), this softwares put > > them together (mostly in the same manner) and build their copy of an > > "ultrafast" asynchronous system. > > > Please, stop using "asynchronous" or "evented" as performance > > mesurement, as Graham already said, an evented environment need that all > > the players are async/evented. And rarely this happen. > > > Django (and wsgi by the current design) are not asynchronous, so do not > > spend more time trying to gather more then a 1% performance improvement, > > and choose the environment looking at first at its robustness and its > > features. > > > And please,please (and please) stop doing benchmark with an hello world. > > Even the most under-talented programmer can optimize his work for this > > kind of app ;) > > > -- > > Roberto De Iorishttp://unbit.it > > JID: robe...@jabber.unbit.it --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RE: How to interpret the performance difference: Tornado vs Django
Considering you mostly run django on a webserver like apache, you need to ask the question if your method of runing python on apache (wsgi or mod-python for instance) runs in a way apache runs multi threaded and multi instance, which it normaly does, in which case itll use as much cares as you throw at it. Or if you use another wabserver like iis or lighttpd, are capable of running multiple cpu's, which all 3 mentioned webservers do. >From your confussion on the subject its clear your knowledge on webservers is >quite limited. Maybe best to read a tone more about it. Sent from my Windows Mobile phone -Original Message- From: ihomest...@gmail.com Sent: woensdag 7 oktober 2009 05:56 To: Django developers Subject: Re: How to interpret the performance difference: Tornado vs Django Thanks to you guys for the insightful discussions and thoughts on this topic. It is always good to hear from many sides to get a complete picture. I agree with your comments about the benchmark thing and that is the also the origin of my confusions when I read the benchmark part in the Tornado doc. Since many have mentioned that django is not an asynchronous framework, this leads to one of my other question: would anyone shed any thoughts on how to configure django to take advantage of multi core machines? Or is there nothing extra we need to do and everything is already taken care of by the underlying django framework on multi cores? Thanks. On Oct 6, 3:23 am, Roberto De Ioris wrote: > On Mon, 2009-10-05 at 22:16 -0700, 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? > > Thanks. > > Once in a while, someone (me included with uwsgi) spit out a new outstanding > deploy technology > forgetting that 99.999% of bottlenecks are on the apps and not on > the webservers. > > Putting all the efforts on speed is now completely useless, all of this > tecnology are heavily based on optimization done by the kernel (epoll, > kqueue, sendfile, vector i/o, varouis aio technics), this softwares put > them together (mostly in the same manner) and build their copy of an > "ultrafast" asynchronous system. > > Please, stop using "asynchronous" or "evented" as performance > mesurement, as Graham already said, an evented environment need that all > the players are async/evented. And rarely this happen. > > Django (and wsgi by the current design) are not asynchronous, so do not > spend more time trying to gather more then a 1% performance improvement, > and choose the environment looking at first at its robustness and its > features. > > And please,please (and please) stop doing benchmark with an hello world. > Even the most under-talented programmer can optimize his work for this > kind of app ;) > > -- > Roberto De Iorishttp://unbit.it > JID: robe...@jabber.unbit.it --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How to interpret the performance difference: Tornado vs Django
Thanks to you guys for the insightful discussions and thoughts on this topic. It is always good to hear from many sides to get a complete picture. I agree with your comments about the benchmark thing and that is the also the origin of my confusions when I read the benchmark part in the Tornado doc. Since many have mentioned that django is not an asynchronous framework, this leads to one of my other question: would anyone shed any thoughts on how to configure django to take advantage of multi core machines? Or is there nothing extra we need to do and everything is already taken care of by the underlying django framework on multi cores? Thanks. On Oct 6, 3:23 am, Roberto De Ioris wrote: > On Mon, 2009-10-05 at 22:16 -0700, 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? > > Thanks. > > Once in a while, someone (me included with uwsgi) spit out a new outstanding > deploy technology > forgetting that 99.999% of bottlenecks are on the apps and not on > the webservers. > > Putting all the efforts on speed is now completely useless, all of this > tecnology are heavily based on optimization done by the kernel (epoll, > kqueue, sendfile, vector i/o, varouis aio technics), this softwares put > them together (mostly in the same manner) and build their copy of an > "ultrafast" asynchronous system. > > Please, stop using "asynchronous" or "evented" as performance > mesurement, as Graham already said, an evented environment need that all > the players are async/evented. And rarely this happen. > > Django (and wsgi by the current design) are not asynchronous, so do not > spend more time trying to gather more then a 1% performance improvement, > and choose the environment looking at first at its robustness and its > features. > > And please,please (and please) stop doing benchmark with an hello world. > Even the most under-talented programmer can optimize his work for this > kind of app ;) > > -- > Roberto De Iorishttp://unbit.it > JID: robe...@jabber.unbit.it --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RE: How to interpret the performance difference: Tornado vs Django
Apache_mod_PHP or Apache_fastCGI, or IIS flavored. Although I've had some good experiences using lighttpd with php too. What I mean with a php server in general is any webserver configured to run PHP websites and static files and nothing else. You can get rather funky results having a webserver setup to run PHP, ASP, Python, JAVA, .NET and other languages all on the same box plus maybe several different database engines. I prefer choosing a technology and sticking with it for the entire website or server. I also adminned a server farm for a hosting company in the past, they had all servers setup to run everything you can imagine, including some servers running fully configured Apache and MySQL instances, configured for PHP all the way to Java, while the servers in question were only used to lease Multiplayer COD and Ghost Recon instances on it. I changed it to have a 4 server pool of PHP servers, an 8 server pool that ran nothing but static files and a 3 server pool with Windows/IIS for ASP and .NET with all the other servers being utilized for game instances. He was able to drop 8 webservers (there were originaly 23 servers that ran websites and web applications) and replace them with boxes better suited for game hosting, because the way I configured the 15 remaining web servers was plenty performant to run what he was hosting (they were really just running 5-10% average load). Way less headaches and much lower maintenance. It's easy to mess up multiple technologies on one server by updating or adding one. Not to mention that most webservers that have too many technologies installed and enabled for use are typically malconfigured and unoptimized because its way to big a headache to even start trying to fix it, while that type of servers is usually managed and in the hands of someone with sub par knowledge of the technologies and just had some external company or the datacenter where they lease the servers set it up like that. -Original Message- From: django-developers@googlegroups.com [mailto:django-develop...@googlegroups.com] On Behalf Of Kenneth Gonsalves Sent: dinsdag 6 oktober 2009 10:42 To: django-developers@googlegroups.com Subject: Re: How to interpret the performance difference: Tornado vs Django On Tuesday 06 Oct 2009 1:53:44 pm TheMaTrIx wrote: > I have a nack for optimizing PHP Webservers what is a PHP webserver? -- regards kg http://lawgon.livejournal.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How to interpret the performance difference: Tornado vs Django
On Tuesday 06 Oct 2009 1:53:44 pm TheMaTrIx wrote: > I have a nack for optimizing PHP Webservers what is a PHP webserver? -- regards kg http://lawgon.livejournal.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RE: How to interpret the performance difference: Tornado vs Django
A server mainly needs to be stable and you only need to start pushing for that 1% more performance when your servers load is over the edge. You can create bottlenecks with misconfiguration, but to misconfigure something, just means you didn't follow the guidelines to establish a basic configuration. As an example how app changes performance while a server mainly needs to be stable. I used to use Mambo and later Joomla for relatively small portal websites for clients. I have a nack for optimizing PHP Webservers and am glad to say that a server I configured or reconfigured usually had a 5 to 10% performance advantage over the stock server with general tweaks everyone does after finding them online. I adminned a 2 Million post forum with about 150K users and an average of 500 concurrent users on the forum and an average of 1.8TB of downloads a month. The board was run on vBulletin, didn't have any trouble handling the traffic, on a single CPU dual core server with 2GB ram and 2 NIC's (to keep download traffic from disrupting web traffic). It all went perfectly well until the sites owner wanted me to install a Joomla Instance on the server to work as a frontend portal for the site, while up to then I had been using a few simple, optimized PHP scripts for the job, the scripts displayed some usefull information concerning download trends, forum trends, new downloads, new threads and some general information pages about the sites subject matter and had a news posting mechanism that pulled data from threads in a news forum. On test server I put a copy of the large forum, installed Joomla, created or used any connectors needed to plug the forum's information bits into Joomla and on the test server it all ran together just fine. I did some load tests and all was far from well. The second I went beyond 50 concurrent users on the site, pageloads and page generation times started going into the seconds, backend scripts that collected and parsed data for statistics, which used to be able to run every 15 minutes without trouble, took over an hour to complete running and downloads went to a crawl. I spent 2 months optimizing and in some cases rewriting from scratch publicly available connectors between VB and Joomla and in the end of the software optimizations the bottleneck was around 150 users. Still far from what I needed. That’s unless I installed Joomla on a separate dedicated server, in that case it was able to run close to 500 concurrent users, but that was really the limit. Considering that we had days where concurrent user numbers could reach up to 10K users online, it was never enough. I proposed to use another framework or that the site owner gave me the time to extend my original optimized and simple portal to whatever he needed added to it. He wouldn't have it and wanted Joomla because it had some nice prefab plugins, and a webbased template builder, so he could change the look of the site for seasonality more easily. So he went with using 2 webservers, one with VB the other with Joomla. The forum running blazing fast, as it always had, the portal part being slow as hell, barely handling the traffic. I guess most of you know that quite a loss of traffic is what followed that decision. In stats, traffic that came to the forums trough search engines and links directly to forum threads stayed stable and the same, but new traffic that used to arrive at the portal index page went from 89% clicktrough to the forum to around 20%. We used to post news about software releases on the portal page, which sometimes brought massive peak traffic after being indexed, with Joomla, not only was SEO crappy and 10x slower when you utilized the SEO facilities included compared to plain PHP urls, but it didn't translate into traffic that well either. The largest peak we had since the move to Joomla were a mere 3000 concurrent users on the forum, while 3000 was what we usually pulled during the evening peak hours. No level of server optimization can get even close to what an optimized application and database layout can do! -Original Message- From: django-developers@googlegroups.com [mailto:django-develop...@googlegroups.com] On Behalf Of Roberto De Ioris Sent: dinsdag 6 oktober 2009 9:24 To: django-developers@googlegroups.com Subject: Re: How to interpret the performance difference: Tornado vs Django On Mon, 2009-10-05 at 22:16 -0700, 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
Re: How to interpret the performance difference: Tornado vs Django
On Mon, 2009-10-05 at 22:16 -0700, 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? > Thanks. > Once in a while, someone (me included with uwsgi) spit out a new outstanding deploy technology forgetting that 99.999% of bottlenecks are on the apps and not on the webservers. Putting all the efforts on speed is now completely useless, all of this tecnology are heavily based on optimization done by the kernel (epoll, kqueue, sendfile, vector i/o, varouis aio technics), this softwares put them together (mostly in the same manner) and build their copy of an "ultrafast" asynchronous system. Please, stop using "asynchronous" or "evented" as performance mesurement, as Graham already said, an evented environment need that all the players are async/evented. And rarely this happen. Django (and wsgi by the current design) are not asynchronous, so do not spend more time trying to gather more then a 1% performance improvement, and choose the environment looking at first at its robustness and its features. And please,please (and please) stop doing benchmark with an hello world. Even the most under-talented programmer can optimize his work for this kind of app ;) -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How to interpret the performance difference: Tornado vs Django
On Oct 6, 4:16 pm, "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 -~--~~~~--~~--~--~---
Re: How to interpret the performance difference: Tornado vs Django
On Tuesday 06 Oct 2009 10:46:44 am ihomest...@gmail.com wrote: > I read this doc about the performance comparison between Tornado and > Django: http://www.tornadoweb.org/documentation comparison between django and tornado? django is a web framework. Tornado is a web server. Whats to compare? one compares platforms for running django. like: apache + mod_python - sucks apache + mod_wsgi - rocks nginx + tornado - rocks big time with nginx handling the media and tornado handling django. -- regards kg http://lawgon.livejournal.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
How to interpret the performance difference: Tornado vs Django
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? Thanks. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
