From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | Antimon <antimon(at)gmail(dot)com> |
Cc: | pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL client api |
Date: | 2006-03-29 21:58:58 |
Message-ID: | 1143669537.3625.180.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 2006-03-29 at 15:22, Antimon wrote:
> Just tried, yes, pconnect boosts multi user performance.
> But causes this:
> http://img526.imageshack.us/img526/6302/pgsql7th.jpg
> :)
>
> Need to modify max persistent connection settings.
I don't thin that doesn't do what you think it does. max persistent
setting in php.ini sets the max number of persistent connections PER PHP
/ web server process.
What web server is that with, btw?
With a web server like lighttpd, you have a "pool" of php child
processes pre-spawned and ready to go, and you limit that pool to
something reasonable.
With apache and other web servers, each web server child process gets
its own php process hanging off of it, and if you've got, say, a default
apache install, that allows up to 150 child processes.
If you're using apache, you're often better off limiting the number of
children to something smaller, or cranking up postgresql allowed
connections to keep up. 150 is usually a bit much. 20 to 50 is
normally plenty for most applications that can benefit from pconnects.
But you're probably better off with something like lighttpd.
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2006-03-29 22:01:23 | Re: PostgreSQL client api |
Previous Message | Rory Hart | 2006-03-29 21:31:49 | Re: Implementation Suggestions |