| 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: | Whole Thread | Raw Message | 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 |