On Thu, July 12, 2007 23:03, Fei Liu wrote: Hello Liu,
> My implementation is now using a 120 pool size (server is configured to > allow 128 concurrently), my bottle neck now is the database. My > connection pool is quickly exhausted in my test. What's a good strategy > to improve the performance? I am thinking of queueing the database > requests and only execute them when a certain number (say 50 sql > statements) is reached? I think 120 is probably still too many. One of the points of having a connection pool is that you can create fewer connections and reuse them. Many web applications get by on <20, as far as I know. Don't create this many unless your testing shows that (1) you need it and (2) it really helps. What you can do is make sure your pooled connections are released regularly, so hopefully you don't need so many. You could allocate them on a per-transaction basis: lock pool, grab connection, unlock pool, open transaction, do work, commit, destroy transaction, lock pool, release connection, unlock pool. "Grabbing" or "releasing" a connection could be as simple as taking it out of a list or setting an "I own it" flag somewhere. > In my case the postgres server simply stops responding after a while and > allocated connection is not released from client...But CPU load is never > really very high...Maybe there is something else wrong. That's beginning to sound more like a postgres issue; people at [EMAIL PROTECTED] may know more about it. Jeroen _______________________________________________ Libpqxx-general mailing list Libpqxx-general@gborg.postgresql.org http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
