Обсуждение: RES: PHP + PostgreSQL

Agreed!

    I am concerning about scability and avaibility and performance.
    Maybe at least 400 users will be online at the same time.


-----Mensagem original-----
De: Frank Joerdens [mailto:frank@joerdens.de]
Enviada em: quinta-feira, 19 de setembro de 2002 14:14
Para: Elielson Fontanezi
Cc: pgsql-general
Assunto: Re: [GENERAL] PHP + PostgreSQL


On Thu, Sep 19, 2002 at 01:52:31PM -0300, Elielson Fontanezi wrote:
[ . . . ]
>        I doing a research about Apache Web Server + PHP + PostgreSQL.
[ . . . ]
>    reliable or not. The pros and set backs about it.

That is a, well, hm . . . rather extremely general question. Could you
be a little more specific?

Regards, Frank

On Thu, Sep 19, 2002 at 02:28:36PM -0300, Elielson Fontanezi wrote:
> Agreed!
>
>     I am concerning about scability and avaibility and performance.
>     Maybe at least 400 users will be online at the same time.

It depends on what these 400 users are doing whilst they're online, how
often they're hitting the reload button, posting stuff, etc.. I'd try to
build a scaled down version of your scenario (e.g. with 5 or 10 users,
or an e.g. php script that simulates those users' behaviour) and then
extrapolate.

PostgreSQL at the moment does not support replication (i.e. it's not in
the main tree - there are solutions out there, about which I don't know
anything though) AFAIK, so you might have to buy expensive hardware
(e.g. a server with multiple processors), or get licenses for a product
that does, if you find that you really need this kind of scalability.

As far as Open Source databases are concerned, it's the best deal in
terms of the kind of support you get on the lists - really awesome.
Featurewise, you're on a par with most of the other major contenders
(except for replication, which might bite you if you really find that
you need the scalability, which is actually rare for web applications).

Performancewise, it's faster than MySQL for UPDATEs (because MVCC is
better than table locking), which is what usually bogs down a server
with many simultaneous transactions. SELECTs are usually not hard to do
fast anyway because especially with web apps, you'd want to have some
kind of caching mechanism.

Regards, Frank

On Fri, Sep 20, 2002 at 10:53:24AM +0200, Frank Joerdens wrote:
[ . . . ]
> SELECTs are usually not hard to do
> fast anyway because especially with web apps, you'd want to have some
> kind of caching mechanism.

I put that really badly: What I was trying to say is that for web
applications in most scenarios, the select performance of the database
itself is not as crucial as some people seem to think. This is because
you're not going to get very far without some caching mechanism anyway,
and if you have a caching mechanism, it depends on how well the system
is implemented. All these benchmarks pertaining to the select
performance of the sql database behind your Apache/PHP app really put
you on the wrong track altogether. It's not how it works.

Mind you, this is still very general, and those are sweeping statements.
It all depends.

Regards, Frank