GrahamDumpleton · November 7, 2012 22:35
diff --git a/gistfile1.txt b/gistfile1.txt
 Update on this - turned out I was hitting this issue:
 http://stackoverflow.com/questions/8198990/pgbouncer-closing-because-unclean-server-on-every-connection

 We weren't getting any of the benefit of pgbouncer because pgbouncer was closing all connections when they were returned to the pool since they were still dirty.  Supposedly the best way to fix this is to use autocommit in django, however that requires a careful audit of wherever you are doing db updates and wrapping that code with something like the @commit_on_success decorator.  Since all of our API calls have the possibility of doing an update, I could take the easy way out and just add django.middleware.transaction.TransactionMiddleware to my list of middleware classes.  Now I'm getting connection reuse from pgbouncer, and not incurring the overhead of establishing a new connection with each db request.  Big improvement, and I'm no longer seeing the strange long periods of time in set_isolation_level (which were obviously due to setting up a connection under high load).
	Update on this - turned out I was hitting this issue:
	http://stackoverflow.com/questions/8198990/pgbouncer-closing-because-unclean-server-on-every-connection

	We weren't getting any of the benefit of pgbouncer because pgbouncer was closing all connections when they were returned to the pool since they were still dirty. Supposedly the best way to fix this is to use autocommit in django, however that requires a careful audit of wherever you are doing db updates and wrapping that code with something like the @commit_on_success decorator. Since all of our API calls have the possibility of doing an update, I could take the easy way out and just add django.middleware.transaction.TransactionMiddleware to my list of middleware classes. Now I'm getting connection reuse from pgbouncer, and not incurring the overhead of establishing a new connection with each db request. Big improvement, and I'm no longer seeing the strange long periods of time in set_isolation_level (which were obviously due to setting up a connection under high load).