Re: maybe Offtopic : PostgreSQL & PHP ?

On Wed, Apr 18, 2001 at 08:54:24AM -0600, Roberto Mello allegedly wrote:
> Ah, I see the problem. When you mentioned there were problems I
> thought you were talking about the connections themselves.
> I am using PHP 4 under AOLserver/OpenNSD, which has been fully
> threaded from scratch (1994) so I hope this won't be much of an issue (but
> then PHP 4 still has threading problems AFAIK).
> Not using persistant connections is just too slow for me. It's
> instantaneous for AOLserver to generate a page, when the same page with the
> connection overhead in PHP takes A LOT longer.

So how does AOLserver/PHP handle connections then? Is AOLserver managing
(pooling) connections for PHP or something like that (like websphere and
nas do for Java programs)? A big problem (in my opinion) with Apache is
that you cannot limit the number of Apache processes that acquire
database links. For instance, it would be great if I could instruct
Apache to direct PHP request to a maximum of, say, 20 dedicated
processes. As it stands now, your best bet is probably a two step
approach; have a reverse proxy (such as a very lean apache installation)
or some other proxy (such as a loadbalancer) redirect requests to
multiple webservers, some of which have the pgsql PHP module.

Another approach we've used for our own development environment (DBL) is
using a SQL proxy. We've placed a proxy between the webservers and the
databases. It provides multiplexing of connections and caching of
queries. Fail-over or load balancing is not implemented, but not that
difficult in our case, since our webservers do not directly update the
databases themselves. There's an Open Source product that provides
similar functionality (I think it's called SQL Relay or something
similar). There maybe be some commercial offerings for Open Source
databases such as pgsql and mysql, but I haven't looked into that.

Of course, having lots of db connections may not be necessary. We're
running one of the bigger news sites in Holland. It's implemented using
Java servlets, run without big-gun application servers such as WAS or
NAS (just the M5 webserver) and it uses PostgreSQL 7.0 for it's data
storage (both images and xml). It runs on a fairly small server and is
able to sustain more than 600,000 hits daily without breaking out in a
sweat. Of course, caching is a big thing, since actually generating a
page may take a second or more, but due to the way we maintain and prime
the cache, the users normally don't notice. However, restarting the
(web) server is a bitch though, since it usually takes 10-15 minutes to
build up a cache big enough to be able to serve most request directly
from the cache. It may be a fairly common setup, but I quite like the
way this system (built by two collegues) turned out. It was our second
attempt at using pgsql for a bigger production site and while we ran
into a lot of problems, in the end it worked out very well :)

Regards,

Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum