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
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 |