Re: Re: re : PHP and persistent connections - Mailing list pgsql-novice

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. :-)

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

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

> > 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
> > (they'll be sitting there doing nothing, or serving images or other
> > static content).
> Just what I was thinking. Connection pooling would avoid that, correct?
> > If your application is big enough you may benefit from serving static
> > content (images etc) from a different server, so the Apache processes
> > with persistant connection to backends are being used more heavily for
> > database work.
> True, but in this case probably moving the database to a different server
> would make more sense because most of the backends would be serving
> content that is completely unrelated to the database.

Well, here's the problem:

1 apache/php/postgres thread = 1 possible persistant postgres connection

if you run up 200 threads on _any_ server instance, that means you need
200 waiting backends, if that server is also doing postgres content
with persistant connections anywhere in that server.

I think the idea being referred to works like this:
In a big, mega-hit app, you put your simple content on a simple server,
so the web pages reference GIF's/frames/whatever stored there, rather
than on a heavy-use box. This means that the clients go to *another*
web server for that non-dynamic content.

> How would persistent connections fit into a dual-server setup where one
> server is handling all of the webserving and the other simply handles the
> database data-serving?

Er... well, if you db load was really heavy, this would make sense,
but your problem is about having all of the webserving in one place.

> The number of backends on the database server would be independent
> of the number of Apache processes on the webserver inasmuch as there
> could be 75 Apache processes but only 25 are connected to backends on the
> database server, correct?

All 75 Apache processes might eventually try to serve up the db pages.

So all 75 *could* eventually want persistant connections. You can't control
which process gets which page.

> There would not necessarily be any Apache stuff on the database server?

Not if you don't want it, no. Keep in mind that using _non_ persistant
connections on this setup will be even slower, as well.

-Ron

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