Re: performance config help

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Bob Dusek <redusek(at)gmail(dot)com>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: performance config help
Date: 2010-01-14 05:47:13
Message-ID: 4B4EAFE1.4050909@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Bob Dusek wrote:
>>> The problem with our "cheap" connection pool is that the persistent
>>> connections don't seem to be available immediately after they're
>>> released by the previous process. pg_close doesn't seem to help the
>>> situation. We understand that pg_close doesn't really close a
>>> persistent connection, but we were hoping that it would cleanly
>>> release it for another client to use. Curious.
>> Yeah, the persistent connects in php are kinda as dangerous as they
>> are useful.. Have you tried using regular connects just to compare
>> performance? On Linux they're not too bad, but on Windows (the pg
>> server that is) it's pretty horrible performance-wise.
>
> Yes we have. Regular connections are pretty slow, even when our
> application server is on the same box as the db server.
>
>>> We've also tried third-party connection pools and they don't seem to
>>> be real fast.
>> What have you tried? Would pgbouncer work for you?
>
> We've tried pgbouncer. It's pretty good.

Oh, also look into mod_dbd . With the threaded MPM it can apparently
provide excellent in-apache connection pooling.

--
Craig Ringer

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Dimitri Fontaine 2010-01-14 10:44:15 Re: performance config help
Previous Message Craig Ringer 2010-01-14 05:45:05 Re: performance config help