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 > 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.9999999% 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 -~----------~----~----~----~------~----~------~--~---
<<attachment: winmail.dat>>
