|
If your app is running under Tomcat, connection pooling is extremely easy to set up from there: It has connection pooling mechanisms built in. Request your db connections using said mechanisms, instead of doing it manually, make a couple of changes to server.xml, and the problem goes away. Hundreds, if not thousands of concurrent users might end up running with less than 10 connections.
>>> Harpreet singh Wadhwa <harpreet@xxxxxxxxxxxxx> 7/9/2010 3:55 AM >>> Thanx you all for the replies. I got a gist on where should I head towards like I should rely a bit on postgres for performance and rest on my tomcat and application. And will try connection pooling on postgres part. And if I come back for any query (related to this topic) then this time it will be more precise (with real time data of my testing). ;-) Regards haps On Fri, Jul 9, 2010 at 1:22 PM, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> wrote: > On 09/07/10 12:42, Tom Lane wrote: >> Samuel Gendler <sgendler@xxxxxxxxxxxxxxxx> writes: >>> On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer >>> <craig@xxxxxxxxxxxxxxxxxxxxx> wrote: >>>> If you're not using a connection pool, start using one. >> >>> I see this issue and subsequent advice cross this list awfully >>> frequently. Is there in architectural reason why postgres itself >>> cannot pool incoming connections in order to eliminate the requirement >>> for an external pool? >> >> Perhaps not, but there's no obvious benefit either. Since there's >> More Than One Way To Do It, it seems more practical to keep that as a >> separate problem that can be solved by a choice of add-on packages. > > Admittedly I'm relatively ignorant of the details, but I increasingly > think PostgreSQL will need a different big architectural change in the > coming years, as the typical performance characteristics of machines > change: > > It'll need to separate "running queries" from "running processes", or > start threading backends, so that one way or the other a single query > can benefit from the capabilities of multiple CPUs. The same separation, > or a move to async I/O, might be needed to get one query to concurrently > read multiple partitions of a table, or otherwise get maximum benefit > from high-capacity I/O subsystems when running just a few big, expensive > queries. > > Otherwise I'm wondering if PostgreSQL will begin really suffering in > performance on workloads where queries are big and expensive but there > are relatively few of them running at a time. > > My point? *if* I'm not full of hot air and there's some truth to my > blather above, any change like that might be accompanied by a move to > separate query execution state from connection state, so that idle > connections have a much lower resource cost. > > OK, that's my hand-waving for the day done. > > -- > Craig Ringer > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance |
