On Wed, 14 Jan 2004, Jón Ragnarsson wrote:
> I am writing a website that will probably have some traffic.
> Right now I wrap every .php page in pg_connect() and pg_close().
> Then I read somewhere that Postgres only supports 100 simultaneous
> connections (default). Is that a limitation? Should I use some other
> method when writing code for high-traffic website?
A few tips from an old PHP/Apache/Postgresql developer.
1: Avoid pg_pconnect unless you are certain you have load tested the
system and it will behave properly. pg_pconnect often creates as many
issues as it solves.
2: While php has pretty mediocre run time performance, it's startup /
shutdown / cleanup are quite fast, and it caches previously executed
pages. Thus, if your pages are relatively small, code-wise, then the
amount of time it will take to execute them, versus the amount of time the
user will spend reading the output will be quite small. So, you can
likely handle many hundreds of users before hitting any limit on the
database end.
3: Apache can only run so many children too. The default for the 1.3
branch is 150. If you decrease that to 50 or so, you are quite unlikely
to ever run out of connections to the database.
4: Postgresql can handle thousands of connections if the server and
postgresql itself are properly configured, so don't worry so much about
that. You can always increase the max should you need to later.
5: Database connection time in a php script is generally a non-issue.
pg_connect on a fast machine, hitting a local pgsql database generally
runs in about 1/10,000th of a second. Persistant connects get this down
to about 1/1,000,000th of a second. Either way, a typical script takes
milliseconds to run, i.e. 1/100th of a second or longer, so the actual
difference between a pg_pconnect and a pg_connect just isn't worth
worrying about in 99% of all circumstances.
6: Profile your user's actions and the time it takes the server versus how
long it takes them to make the next click. Even the fastest user is
usually much slower than your server, so it takes a whole bunch of them to
start bogging the system down.
7: Profile your machine under parallel load. Note that machine simos
(i.e. the kind you get from the ab utility) generally represent about 10
to 20 real people. I.e. if your machine runs well with 20 machine simos,
you can bet on it handling 100 or more real people with ease.
