Re: Decide between Postgresql and Mysql (help of

On Thu, 2006-03-30 at 11:22, Chris Browne wrote:
> cjames(at)modgraph-usa(dot)com ("Craig A. James") writes:
>
> > Gorshkov wrote:
> >> /flame on
> >> if you were *that* worried about performance, you wouldn't be using
> >> PHP or *any* interperted language
> >> /flame off
> >> sorry - couldn't resist it :-)
> >
> > I hope this was just a joke. You should be sure to clarify - there
> > might be some newbie out there who thinks you are seriously
> > suggesting coding major web sites in some old-fashioned compiled
> > language.
>
> Actually, this seems not so bad a point...
>
> If people are so interested in micro-managing certain bits of how
> performance works, then it seems an excellent question to ask why NOT
> write all the CGIs in C.
>
> After all, CGI in C *won't* suffer from the performance troubles
> associated with repetitively loading in Perl/PHP frameworks (which is
> why things like FastCGI, mod_perl, and such came about), and you can
> get a fair level of assurance that the compiled C won't be the
> performance bottleneck.
>
> And yes, it does become natural to ask "why not write CGIs in ASM?"
> ;-)

But as an aside, I've been load testing our web application. We have,
in the test farm, two tomcat servers feeding into three jboss servers,
feeding into a database farm (oracle and postgresql, doing different
things, oracle is the transaction engine, postgresql is the "data
collection bucket" so to speak.)

Our tomcat servers sit at 10% load, the jboss servers sit at 20 to 40%
load, and the Oracle server sits at 100% load.

And the thing is, while we can add load balanced tomcat and jboss
servers as need be, and get nearly linear scaling from them, we can't do
the same for the database. That's going to require vertical scaling.

And that, nowadays, is generally the state of web development. It's not
the language you're using to write it in, it's how efficiently you're
using your database. We can probably tweak the system we're testing now
and get more from our databases by adjusting how hibernate hits them,
and the types of queries that it's throwing, but in the long run, the
bottleneck will always be the database server, because we can throw
relatively small amounts of money at the other layers if they happen to
be bogging down. Not so much with the database.