[Pgpool-general] pgpool vs application managed db connection pooling
Bryan Varner
bvarner at polarislabs.com
Fri Oct 28 14:52:34 UTC 2011
I currently have pgpool in testing under a large(ish) java application.
I have tested all the scenarios you mention, here are my results --
yours will likely vary.
We're using C3P0 for both application level connection pooling, and
statement pooling. Statement pooling has proven to be a huge performance
boost for our application.
> Please share any pros/cons for using:
> 1) just pgpool managed db connection pool vs
Having pgpool underneath will allow us to load-balance selects across
the cluster. Our application workload is insert / update heavy on
regular cycles, but read-heavy for data that's older than 1 hour.
In addition, using pgpool to trigger a failover may be easier than some
other alternatives.
> 2) just application managed db connection pool vs
This is our current production situation. We have a rather strange
application-level pool of pools to balance report queries across the
nodes in our replicated cluster.
I have never had an issue with application level connection pools, they
preform reliably, and work effectively. The overhead involved with JDBC
connections is very high.
I tested removing the application-level connection pool and relying
solely on pgpool, opening connections with the JDBC driver as needed.
The performance was still better than without pgpool, but it was
atrocious compared to with the application level pool in place.
> 3) both pgpool and application managing their own separate db
> connection pools at the same time?
There's some trickery here in configuring pgpool and your application
connection pool so that you don't exhaust the pgpool pool and deadlock
your application pool.
I've seen marked improvement doing select-heavy loads with load-balance
mode enabled. It's really nice.
I have not seen any degradation in performance, I've seen marginal
improvement.
I hope this helps -- I don't have official load-test numbers at this
time, or else I'd be including those here. The pgpool testing we've been
undertaking hasn't made it up to our load-test environment yet -- once
it's there, I plan on reporting my results.
Regards,
-Bryan Varner
> Kind regards,
> Stevo.
> _______________________________________________
> Pgpool-general mailing list
> Pgpool-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pgpool-general
More information about the Pgpool-general
mailing list