On 28 févr. 2013, at 20:09, David Cramer <dcra...@gmail.com> wrote: > Can we please change this so it defaults to off, and just document how to > turn it on and in what situations you should turn it on? >
> In my opinion this default-on feature caters to a very specific audience, and > will cause a lot of unexpected behavior with other users. For the record, the reasoning behind the current default is as follows. By default, Django uses the database session backend. As a consequence, each worker opens a database connection early in the request cycle (in process_request), and keeps it open until the end of the request. I don't have any figures, but I believe that such sites cannot be dismissed as "a very specific audience". When a website grows larger (in terms of traffic), its developers optimize it: put sessions into a cache, disable transaction middleware, turn autocommit on, handle transactions manually, use a database connection pooler, etc. The further along this curve you are, the less persistent connections are useful; they may even become harmful. However, the further along this curve you are, the more you know about database performance too, and the better your ability to determine if persistent connections are useful for your application. The default is targeted at people who wouldn't know what a good value is and who will get the most benefit from persistent connections. You obviously have a strong opinion on what a good value is for your applications (namely, 0) and you won't suffer from an unsuitable default. > Immediately for anyone who has configured more workers than they have > Postgres connections (which I can only imagine is common among people who > havent setup infrastructure like pgbouncer) things will start blowing up. This argument was addressed by Alex earlier in the thread and I agree with his answer. I also find it more helpful to blow up at application start rather than when the traffic exceeds some threshold. > Why should this be the default behavior? > > Unlike MySQL, which already has cheap connections and doesn't suffer this > problem, connections in Postgres add quite a large cost, both on creation, on > allowing them. **Everyone** who cares about their performance on Postgres > should already be using pgbouncer (or some alternative) to offset **both** of > these, not just a single problem which is what Django is addressing here. "**Everyone** who cares about their performance on Postgres" can take 5 seconds to set CONN_MAX_AGE to 0. Persistent connections will improve the situation a little bit for everyone else — people running on a hosted platform, people who don't have the means to configure, run and monitor a pooler efficiently, people who don't even know what a pooler is, etc. > I will happily defend my opinion in person at PyCon in two weeks if it still > remains a default, and anyone is willing to listen, and if you reach out to > the other large (and I dont mean scale) Django users I imagine you will find > a lot of mixed feelings about this default. I won't be at PyCon, but several Django committers will. If a core dev wants to change the default to 0, feel free. (Being the author of this feature, I'm obviously biased towards turning it on.) I don't mind being proved wrong, and I chose to commit this early in the 1.6 release cycle precisely to give plenty of time for such feedback! -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
