On Fri, Jul 24, 2009 at 9:02 PM, Glenn Maynard<gl...@zewt.org> wrote: > By the way, I switched my connections from TCP to a Unix socket with > local authentication and it dropped to 5-10ms. (I suspect it was
If you're using a connection pooler, you don't want to disconnect and reconnect from it all the time--you want to stay connected and let it worry about not keeping idle sessions open. That's its job! Django should keep the connection open, and if people want to run so many Django backends that this creates too many idle connections, then *that* is the exact scenario for using a connection pooler. 100 connections, without connection pooling, with full disconnect/reconnect: 3.385s 100 connections, without connection pooling, with connection reset: 2.681s 100 connections, with pybouncer, with full disconnect/reconnect: 2.908s 100 connections, with pybouncer, with connection reset: 2.754s You're saying that Django should reconnect constantly, and if that's too slow, people should use a pooler to fix it. This is precisely backwards. Django should stay connected, and if people don't want idle connections to the database, *that* is when you use a pooler. The current behavior--avoiding idle connections to the database--is exactly what you're against: the behavior that should be handled by a pooler. That's what they're for. -- Glenn Maynard --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
