Oddly enough, the particular application in question will have an extremely
small user base...perhaps a few simultainous users at most.
As to the testing, I neglected to say early in this thread that my manager
instructed me _not_ to do further performance testing...so as a good
consultant I complied. I'm not going to touch if that was a smart
instruction to give :-)
Brian
-----Original Message-----
From: scott.marlowe [mailto:scott.marlowe@ihs.com]
Sent: Monday, July 07, 2003 1:35 PM
To: Brian Tarbox
Cc: michael.mattox@verideon.com; Rafal Kedziorski;
pgsql-performance@postgresql.org
Subject: Re: [PERFORM] PostgreSQL vs. MySQL
On Fri, 4 Jul 2003, Brian Tarbox wrote:
> I'm actually leaving this list but I can answer this question. Our
results
> were with a single user and we were running Inodb. We were running on
> RedHat 8.0 / 9.0 with vanilla linux settings.
Hi Brian, I just wanted to add that if you aren't testing your setup for
multiple users, you are doing yourself a disservice. The performance of
your app with one user is somewhat interesting, the performance of the
system with a dozen or a hundred users is of paramount importance.
A server that dies under heavy parallel load is useless, no matter how
fast it ran when tested for one user. Conversely, one would prefer a
server that was a little slow for single users but can hold up under load.
When I first built my test box a few years ago, I tested postgresql /
apache / php at 100 or more parallel users. That's where things start
getting ugly, and you've got to test for it now, before you commit to a
platform.
Postgresql is designed to work on anything out of the box, which means
it's not optimized for high performance, but for running on old Sparc 2s
with 128 meg of ram. If you're going to test it against MySQL, be fair to
yourself and performance tune them both before testing, they're
performance on vanilla linux with vanilla configuration tuning teachs you
little about how they'll behave in production on heavy iron.
Good luck on your testing, and please, don't quit testing at the first
sign one or the other is faster, be throrough and complete, including
heavy parallel load testing with reads AND writes. Know the point at
which each system begins to fail / become unresponsive, and how they
behave in overload.