From: | Ned Lilly <ned(at)greatbridge(dot)com> |
---|---|
To: | "Poul L(dot) Christiansen" <plc(at)faroenet(dot)fo> |
Cc: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Great Bridge re-runs benchmark with MySQL "tuned" |
Date: | 2000-08-22 19:10:28 |
Message-ID: | 39A2D024.FD4D05DB@greatbridge.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
See http://www.greatbridge.com/news/p_081620001.html - we increased the
cache, ran a vacuum analyze, a few minor things.
Regards,
Ned
"Poul L. Christiansen" wrote:
> It would be interesting to see how well PostgreSQL performed when it was
> tuned.
>
> Or has it allready been tuned?
>
> Ned Lilly wrote:
>
> > Folks,
> >
> > We posted the following announcement on our website today, at
> > http://www.greatbridge.com/news/press.html.
> >
> > Please feel free to email me off-list with any questions.
> >
> > Thanks,
> > Ned
> >
> > UPDATE, August 22, 2000:
> >
> > MySQL performance improves with tuning suggestions from development
> > team;
> > PostgreSQL still leads all contenders under heavy usage
> >
> > Following our recent release of AS3AP and TPC-C benchmark test
> > results, Great Bridge offered to re-run the tests with tuning and
> > custom configuration settings suggested by the MySQL development
> > team. We did, and we want to share the results.
> >
> > It's important to note that the MySQL configuration originally
> > tested was the default MySQL installation, using the standard
> > MyODBC.dll Windows driver installed by MySQL (for the benchmark
> > software client machine, which ran Windows NT). Probably the most
> > significant change came from substituting a faster driver, called
> > MyODBC2.dll; according to the MySQL development team, the default
> > driver is used for debugging purposes, and is known to be slower in
> > production environments.
> >
> > At their suggestion, we also implemented the following tuning
> > settings:
> >
> > * key_buffer=64m
> > * table_cache=256
> > * sort_buffer=1m
> > * record_buffer=1m
> >
> > So what were the results? MySQL did significantly better across the
> > board, averaging 69% more transactions per second in this tuned
> > environment, and exceeding Postgres' raw performance until the
> > seventh concurrent user. Its performance peaked at 1,321 tps (at 3
> > users), but still started to fall off about the same point as in the
> > previous test (4 users). See graphic
> > (http://www.greatbridge.com/img/as3ap_new.gif)
> >
> > What does this mean? Our interpretation is that, properly
> > configured, MySQL is indeed a faster performer in raw read-only
> > databases with 6 or fewer users. We should note that these tests
> > results do not represent the full suite of AS3AP tests - only the
> > multiuser ir_select (information retrieval) test. Other tests in the
> > AS3AP suite require views, which MySQL does not currently support.
> > We should also note that the TPC-C test, which simulates a more
> > robust OLTP environment, still would not run under the tuned MySQL
> > configuration, primarily due to SQL compliance issues (see Richard
> > Brosnahan's analysis elsewhere in the main story). But overall,
> > MySQL acquitted itself well when expertly tuned for the AS3AP
> > ir_select test.
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Sears | 2000-08-22 21:10:27 | hidden data fields |
Previous Message | Stephan Szabo | 2000-08-22 19:09:08 | Re: Foreign key to all inherited tables |