Re: Reason for autoindexes_primary_keys?
To my knowledge MySQL has always created indexes for primary and Unique's automaticly. This probably being the reason why it doesn't need that option to be set in the mysql db backend. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] 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 > add more comments about how the experiment is setup. > > The cont
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: CSRF changes - backwards incompatible
I don't understand something here. csrf is stated to be a option that needs to be enabled if you wish to use it for views, yet I just ran a trunk sync and boom, django-pages-cms is busted, without me enabling anything. Is it an always on feature or is something funky? On 27 okt, 14:17, Luke Plant wrote: > On Tuesday 27 October 2009 13:07:14 rebus_ wrote: > > > And there are also some typos in guide: > > Cheers! Fixed now. After this patch, I won't be sad if I never have > to type 'csrf' (or 'crsf') ever again :-) But unfortunately I will... > > Luke > > -- > Environmentalists are much too concerned with planet earth. Their > geocentric attitude prevents them from seeing the greater picture > -- lots of planets are much worse off than earth is. > > Luke Plant ||http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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: CSRF changes - backwards incompatible
I fixed the django-pages-cms app by adding the csrf token tags into the POST forms in the apps admin pages. On 27 okt, 15:36, Luke Plant wrote: > On Tuesday 27 October 2009 13:30:42 TheMaTrIx wrote: > > > I don't understand something here. csrf is stated to be a option > > that needs to be enabled if you wish to use it for views, yet I > > just ran a trunk sync and boom, django-pages-cms is busted, > > without me enabling anything. > > The CSRF protection is enabled by default in MIDDLEWARE_CLASSES, for > the unlikely scenario that you haven't set that setting. This is as > documented. > > It is also enabled for all contrib views, as documented. That can > break if you using views from contrib apps, and have supplied custom > templates which don't have the CSRF token. > > Beyond that, I'll need more details! > > Luke > > -- > Environmentalists are much too concerned with planet earth. Their > geocentric attitude prevents them from seeing the greater picture > -- lots of planets are much worse off than earth is. > > Luke Plant ||http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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: George Carlin comedy
Bah, exploiting the death of a comedy genious and true patriot like this. I shit on you spammers. 2008/7/13 mangaboy008 <[EMAIL PROTECTED]>: > > George Carlin comedy > > George Carlin comedy, movies, pictures, wallpaper, download > > http://english1.isoshu.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
