On Mon, Aug 10, 2009 at 3:16 PM, Allan Kamau<kamauallan@xxxxxxxxx> wrote: > On Mon, Aug 10, 2009 at 7:49 PM, Vick Khera<vivek@xxxxxxxxx> wrote: >> On Mon, Aug 10, 2009 at 9:46 AM, Bill Moran<wmoran@xxxxxxxxxxxxxxxxx> wrote: >>> We have servers using about 200 connections on average ... it climbs up >>> to 300+ during busy use. I've seen it peak as high as 450, and we've seen >>> no performance issues. >>> >>> This is a quad core with 4G of RAM. Of course the OS isn't windows, it's >>> 64 bit FreeBSD. >> >> I too run 64bit FreeBSD 7.2. However in my primary use case, anything >> short of 20GB of RAM makes the application very unresponsive when many >> customers are online. We usually don't have more than about 45 to 50 >> connections simultaneously. My general-use Pg server has 4GB and that >> is more than adequate for the miscellaneous uses of blogs, ad servers, >> and drupal installations. >> >> -- >> Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general >> > > > Hi Kobus, > > My simple (perhaps wrong) understanding of how DB connection pooling > works is that no active connection(s) can be shared. The connection > pool manager may however assign a free connection from the connection > pool to service a connection request, and a connection is usually > declared as free when the application having the active connection > closes it (or returns it to the pool in a connection pool specific > manner). > If this is correct, having an application request for a connection at > the start of a session then holding on to it for the duration of the > session may yield at least as many connections to the DB as there are > sessions. It may then be advisable to (re)write the application to > open (request for a connection from the pool) and close (return a > connection to the pool) DB connections for each logical data > transaction (or group of closely associated transactions). Since in > your case a code rewrite seems unfavourable (due to time pressure) the > DB connection pooling option may not be viable as you may have > noticed. Yeah, from what the OP stated as requirements, I'm guessing the one they can push back on the easiest is to get more memory and run run Linux / BSD / OpenSolaris instead of Windows server. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
