Performance optimization is never ending story, you can virtually always find something else to optimize but while on generic system, not tuned by expert you often can get significant performance increase in the matter of hours further performance improvements become more and more time consuming and expensive and gains smaller.

This observation does not only apply to MySQL but to systems running other databases or no database at all as well.

So how does System size come in play here ? Well it is system size and scale what may define how much performance you need to squeeze out, and also how your scaling is set up.

For smaller systems lets say running couple of MySQL servers running another couple can be cheaper than serious application changes and this can be good way to go if you're not expecting major growth.

This however implies two things - first you can scale system by adding more servers, because scaling up …

Solid contributes additional open source code…Medsphere releases Community Editions of OpenVista…Zenoss celebrates its one-year anniversary…and more…

Solid Contributes New Database Benchmark Suite to Open Source Community, Solid Information Technology (Press Release)

Medsphere Releases Community Editions of OpenVista EHR Platform, Medsphere Systems (Press Release)

Zenoss Marks One Year Anniversary on SourceForge.Net with 130K Downloads and Top Ranking Among Open Source IT Monitoring Projects, Zenoss (Press Release)

…

The two big changes in 0.5 are that I fixed a memory leak and it now has its own information schema table on statistics.

For example:
mysql> select * from information_schema.memcache_servers;
+----------------+-------+---------------+-------------+-------+---------------------+-------------------+-----------------------+------+------+------+--------+------------+---------------+----------------+
| NAME | COUNT | CURRENT_ITEMS | TOTAL_ITEMS | BYTES | CURRENT_CONNECTIONS | TOTAL_CONNECTIONS | CONNECTION_STRUCTURES | GETS | SETS | HITS | MISSES | BYTES_READ | BYTES_WRITTEN | LIMIT_MAXBYTES |
+----------------+-------+---------------+-------------+-------+---------------------+-------------------+-----------------------+------+------+------+--------+------------+---------------+----------------+
| localhost:6688 | 2 | 5 | 39 | 399 | 2 | 65 | 3 | 236 | 39 | 197 | 39 | 4669 | 9546 | 67108864 |
| …

MySQL Table Checksum is a tool to efficiently verify the contents of any MySQL table in any storage engine. You can use it to compare tables across many servers at once. The output is friendly and easy to use, both by eyeball and in UNIX command-line scripts. The provided MySQL Checksum Filter helps you winnow output so you only see tables that have problems.

http://www.webpronews.com/topnews/2007/02/26/techcrunch-others-love-linux-mysql

I’m not quite sure what to say about this article, except that a sample of 7 “big” sites showed that the LAMP[hp] stack was heavily used. Perhaps, “And this is news?”

JasperSoft Corporation and MySQL AB today announced the availability of Jasper for MySQL: OEM Edition, a suite of operational reporting products that includes a high-performance interactive report server, a graphical report creation tool, and a pixel-perfect reporting system with dashboards, tables, crosstabs and charts.

Oh, the silly things incumbent vendors like to say about open source. One oft-repeated line from Oracle is that MySQL is "lightweight" or in some way inferior. If "inferior" means "routinely handles mission critical, backbreaking workloads that Oracle cannot muster or that no sane person would apply Oracle to," then, yes, I suppose it is lightweight.

As Zack just posted over on his blog, Pingdom did a survey of "massive" web sites (Meebo, YouSendIt, Alexaholic, TechCrunch, FeedBurner, iStockPhoto and Vimeo) to see what they're running. Six out of seven run LAMP, with MySQL being the "M."

So, again, if you've got a lot of money to spend, want to waste it on licenses, and don't need a best-in-class database, Oracle or DB2 might be for …

Somewhere in the last week I got a simple request, a user wanted table discovery for the memcached engine.

Both the Archive and Cluster engines support this.

Take an archive .ARZ table in 5.1, move it to another server. If you SELECT or INSERT off the table name it will be "discovered" immediately. The FRM just appears and everything just works (which means that yes in 5.1 all you have to do is save the ARZ file and you are set... no need for the FRM). Using archive_reader you can even make an online copy of the table (this was a feature request from one of the Livejournal developers last year at the user's conference).

Cluster has a similar mechanism. If you create a table on one front end MySQL server, all other MySQL servers that are talking to that cluster discover the table. The reason that this is possible is that the MySQL server just speaks to one cluster at a time.

The memcache …

Pingdom, an online web site monitoring service, surveyed 7 massive sites to determine what infrastructure software they're running.  The sites included Meebo, YouSendIt, Alexaholic, TechCrunch, FeedBurner, iStockPhoto and Vimeo, all of which are high volume Web 2.0 sites.  As it turns out the LAMP stack is being used in 6 out of 7 of these sites. According to the article, MySQL dominates the database selection among high volume web sites:

With open source ruling the game it shouldn?t come as a surprise that the database of choice for all but one of the sites is MySQL, the ultra-popular Swedish open-source database.

?The features that you get for free on MySQL, with replication, in-memory and fault-tolerant databases (if using MySQL cluster), transaction support, and the wicked performance, cost thousands of dollars with …

The price for a 160 Gbyte disk will be around USD 15'000. This is still a bit expensive. But the access time is around 0.5 ms (both for reading and writing) which is around 10 times faster than a normal 15'000 rpm SCSI disk! The disk has NO cache because it is a cache itself (according to the supplier. Maybe this will change in the future). And the lifetime of a cell is > 5 mio writes. For the same performance one needs usually an array of around 10 disks. If your database is heavily write-I/O bound you should consider this solution.