On Fri, Jul 24, 2009 at 8:36 PM, Andy<[email protected]> wrote: > > On Jul 24, 4:39 pm, James Bennett <[email protected]> wrote: >> Except this is what it turns into. So suppose a patch is added which >> does nothing except keep the database connection open; well, that's >> problematic because it means a server process/thread that's not >> handling a request at the moment is still tying up a handle to a DB >> connection. So somebody will say it'd be much better if Django >> maintained a pool of connections independent of request/response >> cycles, and just doled them out as needed. > > I think you're mixing 2 different things together: persistent > connection & connection pooling. > > There's no reason that you can't have persistent connection without > connection pooling. > > For connection pooling you can make an argument whether it belongs in > an ORM or not (although SQLAlchemy supports connection pooling just > fine) > > But on the other hand if all a user wants is simple persistent > connection then it would seem logical for the ORM to provide that. > > Ideally Django should offer choices to users: if a user doesn't mind > tearing down and building up a DB connection every time a request is > processed, he could use non-persistent connection, but if he wants to > save that time & reuse DB connection, he should be able to choose > persistent connection. > > >> if you've got enough traffic >> through your app that the overhead of DB connections is problematic, >> you should be using one of those tools. > > But this isn't about traffic at all. It's about latency, which has > nothing to do with traffic. > > Amazon has done studies on the effects of response time. They varied > the response times of their website and observed the resultant changes > in user behavior. What they found is that for every 50ms increase in > response time, the rate at which users order an item drops by 10%. > > Seen under this light, the additional 150ms latency resulting from non- > persistent DB connection is huge - it implies almost 30% fewer > customer orders. And it has nothing to do with traffic. > > I could be running a tiny e-commerce site. My traffic could be > minimal. And I probably wouldn't have the expertise/time/money to run > a pooling system for my tiny site. But I still wouldn't want to lose > 30% of my orders just because I can't have persistent DB connections. > > > > > > > >
"Seen under this light, the additional 150ms latency resulting from non- persistent DB connection is huge - it implies almost 30% fewer customer orders. And it has nothing to do with traffic." I'd just like to take a moment to point out that that simply *cannot* be, else the only logical conclusion would be that .5s of latency results in 0 sales, which plainly makes no sense. It's also worth noting, that as James has pointed out, if you merely want to persist connections it's a matter of unregistering the signal handler and registering your own to reset the connection. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
