4 ms·
Why would you insist on creating and destroying a db connection on each request? We stopped doing that decades ago.
by vampirechicken 14y ago
Why would you insist on creating and destroying a db connection on each request? We stopped doing that decades ago.
- jaytaylor 14y agoDjango hasn't stopped insisting on that... v1.5 might have pooling, but it's taken them a long time to get connection pooling in.
- obviouslygreen 14y agoForgive my ignorance, but isn't this the point of something like pgpool? I didn't think connecting to a connection pool would be as expensive as connecting to the database itself (if it is, then my next question would be: What's the point of a connection pool? Because clearly I've missed something one way or the other).
- jaytaylor 14y agoYes, but pgpool isn't always an option. If you use Heroku's Postgres service, you do not have sufficient privileges to run the commands to attach to software like pgpool. The only way we were able to get connection pooling working in django 1.3/1.4 was to use django-dbpool[0]. It works okay, but is still pretty sketchy compared to the connection pooling libraries available for the JVM like BoneCP or C3P0. [0] https://github.com/gmcguire/django-db-pool https://github.com/gmcguire/django-db-pool
- talmirza 14y agoYou can still us pg_pool with heroku.
- obviouslygreen 14y agoUnderstood, thank you for the clarification.
- stefantalpalaru 14y agoYes, connecting repeatedly to pgpool is less expensive than doing it directly to postgres. Not having to connect repeatedly to anything is even better.
- taude 14y agoWow. I'd just have assumed that connection pooling was default in all these modern web frameworks. I guess this is one area where Enterprise means you get what you pay for? Example: ODBC connection pooling with ASP pages back in the late '90s.
- the_mitsuhiko 14y agoConnection pooling in postgres can actually be counter productive with high concurrency. Postgres scales very badly to high number of connections.