Re:10 000 concurrent real-time connections to Django
by vampirechicken on Tuesday March 26, 2013 @07:47PM
(#5446796)
Why would you insist on creating and destroying a db connection on each request? We stopped doing that decades ago.
[ Parent
| on HN ]
Re:10 000 concurrent real-time connections to Django
by jaytaylor on Tuesday March 26, 2013 @08:16PM
(#5446926)
Django hasn't stopped insisting on that... v1.5 might have pooling, but it's taken them a long time to get connection pooling in.
Re:10 000 concurrent real-time connections to Django
by obviouslygreen on Tuesday March 26, 2013 @08:42PM
(#5447026)
Forgive 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).
Re:10 000 concurrent real-time connections to Django
by jaytaylor on Tuesday March 26, 2013 @09:59PM
(#5447310)
Yes, 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.
Re:10 000 concurrent real-time connections to Django
by obviouslygreen on Wednesday March 27, 2013 @01:03AM
(#5447896)
Understood, thank you for the clarification.
Re:10 000 concurrent real-time connections to Django
by talmirza on Tuesday March 26, 2013 @11:47PM
(#5447687)
You can still us pg_pool with heroku.
Re:10 000 concurrent real-time connections to Django
by stefantalpalaru on Wednesday March 27, 2013 @07:51AM
(#5448818)
Yes, connecting repeatedly to pgpool is less expensive than doing it directly to postgres. Not having to connect repeatedly to anything is even better.
Re:10 000 concurrent real-time connections to Django
by taude on Wednesday March 27, 2013 @09:10AM
(#5449149)
Wow. 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.
Re:10 000 concurrent real-time connections to Django
by the_mitsuhiko on Wednesday March 27, 2013 @09:41AM
(#5449293)
Connection pooling in postgres can actually be counter productive with high concurrency. Postgres scales very badly to high number of connections.