Re: Great Bridge re-runs benchmark with MySQL "tuned"
От | Ned Lilly |
---|---|
Тема | Re: Great Bridge re-runs benchmark with MySQL "tuned" |
Дата | |
Msg-id | 39A2D024.FD4D05DB@greatbridge.com обсуждение исходный текст |
Ответ на | Great Bridge re-runs benchmark with MySQL "tuned" (Ned Lilly <ned@greatbridge.com>) |
Список | 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.
В списке pgsql-general по дате отправления: