Re: Re: re : PHP and persistent connections

On Fri, Nov 24, 2000 at 12:52:34AM -0700, some SMTP stream spewed forth:
> GH wrote:
> > On Fri, Nov 24, 2000 at 03:17:59PM +1100, some SMTP stream spewed forth:
> > > Howdy,
> > > > It turns out that the number of max_persistent
> > > > is linked to the httpd processes in some
> > > > difficult-to-describe way.
> > > It's not that hard to describe. The max_persistent/max_links values are
> > > per Apache process.
> > It was difficult to describe because I was not recieving consistent
> > results in experiments due to a number of factors. It makes sense now.
>
> I've copied this email exchange over to my PHP folder.. I see what I can do
> do to improve the online documentation. :-)

Great. Thanks.

>
> > Well, see, the thing is, we do webhosting for a number of different
> > domains from the same server so the number of MaxClients needs to be
> > high. I think that 300 is obscene, as the server is not powerful enough
> > to handle 300 apache processes without dumping a large number of them
> > into swap space, not to mention the processing, but no matter what, we
> > would have several extra postgres backends just hanging around wasting
> > ram.
> > Only a few unique persistent connections would be in use at any given
> > time as only a few domains use the database.
>
> Give them their own apache? You can set up two apache instances on one box,
> set up one with lots of backends, set up the other to match the applicable
> db usage...
> You could make a postgres+apache box for these few clients...

Er, I think I missed something.
You mean give them their own Apache instance using a seperate ip?

Is it /possible/ to have a group of httpd processes (Apache) share a
group of Postgres backends without having one backend to one httpd?
That would be connection pooling, correct? Which is not yet possible?

>
> > This has made me realize just how completely braindead our server setup
> > is. ;-) It seems that we would to bring up a seperate database
> > server, very soon.
>
> Depends on the load. I'm serving 429 domains off of PHP/PostgreSQL,
> using non-persistant connections (even though almost every page has
> a select or two), and it's working just fine. My biggest selects only
> return a few hundred rows, my small inserts/updates are done in PHP,
> the big ones (4,000+ rows) are just parsed into files that a Perl/cron job
> takes care of them. It also depends, obviously, on how you write your
> code for all of this, how good the hardware is, etc.
> (PII/500, 512Mb of RAM, RH 6.2 for the above)

That makes sense. The only reason I am so zealous about persistent
connections is that I have seen them be 3 times as fast as regular
connections.

>
> > > Obviously this isn't the most efficient use of backends because a fair
> > > amount of the time the Apache processes won't be using them at all

My main question now is, how can I avoid this?
I would have to go to non-persistent connections, correct?
I think I further understand things now.

So, persistent connections create a one-to-one ratio of
db-using Apache processes and Postgres backends, no matter what?
The only way to avoid such a one-to-one setup would be to
use non-persistent connections or do connection pooling?

So, even if the database were running on a seperate server,
each apache procees on the main server would require one backend process
on the db server?

>
> -Ron
>
> --
> Brought to you from iBop the iMac, a MacOS, Win95, Win98, LinuxPPC machine,
> which is currently in MacOS land. Your bopping may vary.