Procedure Analyse helps you find the optimal data type for the column values in a table.

Usage is very simple:

SELECT … FROM … WHERE … PROCEDURE ANALYSE([max_elements,[max_memory]])

A range of statistics and recommended data types and are returned for each column in your table.

For more information see the MySQL Docs on using Procedure Analyse.

When discussing performance no opinion should be accepted without a metric

One of the great things about Rails is there is a plugin for just about everything and collecting performance metrics is no exception. Most of this is because of Ruby and it’s incredible meta-programming flexibility (but that’s another story). Rails has built-in support for some basic performance monitoring on the request stack (although in recent versions this has been extracted into a plugin), but there are some excellent alternatives.

RPM by NewRelic:

New Relic RPM is a Ruby on Rails performance monitoring application that lets you see and understand application performance metrics in real time so you can fix Rails problems fast. RPM is intuitive. It’s granular. And, it’s a 10-second Rails plug-in install.

metric_fu on GitHub:

metric_fu is a set of rake tasks that make it easy to generate metrics reports.  It uses Saikuro, Flog, Rcov, and Rails’ built-in stats task to create a series of reports.  It’s designed to integrate easily with CruiseControl.rb by placing files in the Custom Build Artifacts folder.

There are some great screencasts on Scaling Rails available from New Relic’s Rails Lab. And yes, scale is orthogonal to performance, but some of the discovery techniques are the same.

Updated:

A commenter has correctly pointed out that metric_fu is not a performance anaysis tool as such. I guess the subtext of what I am saying is that tools like these help track complexity – and complexity is often one of the underlying causes of performance issues.

As is typical in any contact with performance issues, the problem isn’t particularly with the code (as in, it can probably be fixed), but with the ongoing discussions with the team.

So much of performance is really voodoo and superstition, and everyone has their own beliefs. Some are valid, of course, but in my experience there is always someone going on about using single (‘) instead of double (“) quotes or something similar.*

This leads me to the only rule you really need in these situations:

When discussing performance no opinion should be accepted without a metric

If you don’t have any metrics you both don’t know what your performance issue actually is, and without knowing what your problem is you can’t possibly have a solution.

* In PHP, a string defined ’string’ is faster than “string” because the latter will interpolate and render variables. However, this level of “faster” (or ‘faster’) is so small as to be irrelevant and any discussion is a distraction.