Note This Article was actually written back in May after the UC at the request of Linux Magazine, through a series of events It went unpublished. Between then and now Jeremy ended up doing a great job covering most of the topics, so in the end it was unneeded. Now I had this completed article and thought, what should I do with it? In the I decided to publish them here. Also note I did update a few items.

As more companies move to MySQL and the demands for data increase, we push the bounds of the database further. The challenges large Web properties (who have pioneered many of the large MySQL deployments) faced when they stored 50GB of data and had 5,000 users were nothing like the challenges of storing 500GB of data supporting 100,000 users. Today, as we are seeing more and more 10+TB-sized datasets being …

An often overlooked and way underrated component to any site is the collection and reporting of solid historical performance metrics.   Don’t get me wrong, everyone collects some sort of web page stats, has access to mysql status variables, and uses top to check cpu and process stats ( what else does anyone need right?).    But the metrics I am talking about are not your simple # of pages,# of users, apache log metrics that everyone has in their web server, nor are they point in time cpu stats, or cumulative row accessed counters.  No, we  are talking about true performance stats, gathered over a long period of time.  These stats can be used for troubleshooting, trending, and make great art and conversation pieces ( have seen my one of a kind CPU graph).

Think of it this way,  someone complains your site is slow.  They say when they hit the first page it just seems sluggish.  What does …