Now that you know what you want to write about, the next step in the process is to gauge the amount of interest there is in your upcoming product.

I couldn’t understand some parts of this article, but it sounds interesting…

Benchmark was Application benchmark rather than poor database benchmark. We picked to go with PHP not Java and got best results this way. There are actually more than one MySQL implementation and the fact someone had done poor implementation with Java which works better with MonetDB than with MySQL does not prove much. I mean if we would provide optimized Java solution in might have been faster with MySQL or might have not – we do not really know.

Speaking about OutOfTheBox performance of MySQL – simply forget about it. Out of the box MySQL is tuned to consume 16-32MB of RAM so you can install it and have it running on your laptop without affecting other things. For real workloads you need to tune it ie by using one of sample configurations. This may be good or bad but not relevant benchmark results

Regarding MySQL Performance – sure there are cases when performance is poor, TPC-H is one especially bad. It is also true you can run out of memory on misconfigured MySQL.

All benchmarks are different and results in one often do not have anything to do with results in other, even if benchmarks are similar. I never said MySQL has best performance for every workload – for this particular one it has pretty good results however.

Moreover, we have run many examples where out-of-the-box processing of MySQL has questionable performance. A educated DBA is necessary to improve it. A simple run of a TPC-H SF-N, where N brings you just out of memory is sufficient to experience a dreathfull system. Clearly a market niche to generate revenues.

From a technology point of view, it would be nice if the MySQL guys again re-installed and publicly sql-bench results on multiple platforms and solicit a continuous comparison. Not to mention the multi-user version long time ago promissed.

regards, Martin

The difference is Dell used original Dell DVD Store MySQL/PHP sources, but in C’T competition optimized
by MySQL Benchmark Team. Also there are different HW configurations.
Sorry no English version, and I don’t think it will be available.
If you are looking for optimized version you can download it here: http://www.heise.de/ct/dbcontest/teilnehmer.shtml
(again German, but Google Translator should help).

Best,
Vadim!

I noticed that the MySQL results in the PR as 3,663opm was different from the result(1967opm) in Dell’s publication for the DVD online store test on the Dell PowerEdge2800 at: http://www.dell.com/downloads/global/solutions/mysql_network_2800.pdf?
Is there any HWs configuration, or MySQL/PHP/driver source(is it different versions of the src:linux.dell.com/dvdstore in the two publication?) and tuning changes causing the differnce result? Or it will be great if there is English version of the report for the PR result including the above information.

Thanks!

I can guess that there are more than one sql access involved (cached or not cached) for each order to complete through this virtual dvd store.

Your comment about transactions being slower in MySQL doesn’t necessarily apply. For example, LiveJournal switched from MyISAM without transactions to InnoDB with transactions and saw a big increase in the amount of work their (write-limited) servers could do. Which way is faster will depend on the situation. Sometimes that can be using MyISAM for the non-transactional work (say a catalogue updated daily) and InnoDB for the transactional part, sometimes pure InnoDB works best.

You’re not really likely to persuade me that MySQL is slow, since I am somewhat involved with a place doing a couple of billion queries per day on it (on multiple servers). We wouldn’t still be using it if it was actually slow rather than fast. Same applies to the many other really busy and big places that use it.